Announcement Announcement Module
No announcement yet.
Overview of Spring Rich Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Overview of Spring Rich


    I'm new to Spring, and in fact, I'm fairly new to Java in general (my main experience is with Win32 development using Borland Delphi/C++Builder). We're currently looking into starting a new open-source java-based ERP solution (in French), and so we're investigating existing solutions to see what, if anything, would answer our needs.

    I'm currently reading a book about Spring, and it seems very useful, though I have no experience with (nor use for) advanced J2EE development, I'm more interested in rich clients -- an area which the Java world seems to have largely neglected for many years.

    I am therefore interested by the rise of both Spring RCP and Eclispe RCP, which both seem to be addressing some (though not all) of the problems that I can see, related to GUI development with Java.

    So could someone give me a brief overview of the general philosophy and functionality of Spring RCP? We have some ideas of what we want, and if we can't find it elsewhere, we are planning to start an open source project to manage it, but if possible, we'd of course like to join our efforts with others, and build on an existing framework, such as Spring, so as to avoid reinventing wheels crooked. Here, in a nutshell, is what we're after:

    1) A multi-layer framework, allowing clear separation between business logic from data-access and presentation. Spring seems to do a lot in that direction, which is why I'm interested in it.

    2) A simplification and abstraction of GUI coding, so as to enable several things:

    - End-user personalisation capabilities (using XML to describe the user interface and the links between the available actions (coded in Java) and the UI elements). This means, ability to add widgets, change label, add columns to grids, etc.

    - Simplification of GUI coding: the GUI would be coded, not by directly programming to the APIs of the chosen presentation technology (SWT, Swing, AWT, RSWT, JSF, JSP, Flash, etc), but by using high-level abstractions that would represent high-level, logical concepts that would be interpreted in different ways for different presentation technologies. For example, there could be a ActionPane class, a DataGrid class, a TitlePane class, all of which could be created, layed out, and manipulated in Java code in order to provide the logic of the GUI, without actually programming directly to the APIs.

    - This would mean that you would eliminate a good deal of redundent GUI programming: whether you're targetting a web interface or Swing or SWT or a mobile device, the basic logic and layout of your interface will stay the same, only the actual presentation technology will differ.

    - It would also mean that transition between Swing and SWT (for example) could be done transparently of your application. All that would have to be recoded would be a thin layer, that would interpret and render the high-level components in terms of real GUI controls of the chosen GUI framework, but the logic and layout of each window of the application would remain the same.

    3) User editable styles. The idea would be to make something similar to CSS, but for all presentation technologies, rather than for HTML only. In other words, each application could define a set of styles that would be used in different windows of the application. Then, the precise rendering of each style for each presentation technology could be defined (in XML), either by the developer or even the end-user. This would have all the advantages that CSS offers, but which are currently unavailable for GUI developers (mainly, that if you use the same style in multiple places, the actual look of all places can be changed by simply editing the style).

    4) An advanced plugin framework. For this, I think Eclipse RCP or JPF would do the job nicely, except that it would have to integrate smoothly with all the other features above. In other words, a plugin should be able to easily define actions, modify (or add) business logic, define new windows or window templates, edit (or add) styles, and edit (or add) XML window presentation views.

    - Do you think this is workable?
    - How much of this does Spring RCP already handle?
    - Would others be interested in a framework like this, as well as possibly helping to develop it?
    - Should we make a sub-project of Spring RCP, or would it be better to integrate it into Spring RCP?
    - Are there other projects than Spring RCP that would be a better basis for us to build on?

    Thanks in advance,
    Jonathan Neve.

  • #2
    You're new to Java? Buy a book about Swing, write all the boilerplate code (or maybe generate parts of it with NetBean's Matisse).
    Don't start with spring-richclient, as it's not easy to start with for experienced java developers (at the moment, we're working on it) and you won't see the advantage of spring-richclient doing all the boilerplate code. Spring-richclient is not yet mature, keep an eye on it though

    However, do go with spring (even if you don't get it yet that doing initialization that way is a lot better), Hibernate-annotations (if you're using a database) and Acegi (if you need security). Those are mature.


    • #3
      The idea of trying to abstract GUI's from Swing/SWT/JSP/Midlet implementation is appealing, but I don't know of anyone actually suceeding, because the common API could end up with very very few functionality.
      In spring-richclient we're using spring-binding (also used in spring's web tier), so that part is already abstracted slightly. Swinglabs is trying the same between SwingX and JSF.


      • #4
        Hi Geoffrey,

        Thanks for your replies. As I said, I'm a bit new to Java, but I do have enough experience with development in general to be able to appreciate the value of the simplifications that Spring offers. Furthermore, I've had (limited) experience with Swing, enough to dislike its way of doing things. Frankly, coming from a the world of RAD, it seems hardly conceivable to give up so much productivity (in particular, I strongly dislike the heavy way Swing has of handling events, which, in practice, nearly forces you to make an anonymous class for every type of event you want to receive...).

        Anyway, as a result of this, I've been thinking along these lines for a long time. I'd love to be able to switch to Java, but I honestly don't know how anyone, in the current state of affairs, could possibly switch from Borland Delphi to Java, if they are used to building GUI applications. Java seems to have been focusing, since the beginning, mainly on web and J2EE, and stuff like that, but there has been very little effort (until Eclipse) to make GUI development possible.

        (As an aside, I started a project along these lines a while ago, though with hindsight, I don't think it will ever take off, because it was both too ambitious, and also had the disadvantage of trying to carry over into Java some of the limitations of tools like Delphi or VB which are all about RAD more than MVC. You can have a look at it here: I might try to resurrect it as an Eclipse plugin after our new project is finished.)

        Now, we have recently decided to create an opensource ERP for the French market (which is exactly what we're already doing in Win32, though not open-source). This has boosted my previous ideas into a more serious project, which we intend to start developing shortly. I was just trying to find out what would be the community interest in such a tool, and whether there are any other projects out there with similar ambitions, so that we could join efforts. By your answer, I take it that such is not really the case.

        My question then remains, as to the community interest in this. We intend to develop something along these lines regardless of the community, if for no other reason than for our own use, but of course, we would be glad for any constructive criticism of the idea and design, as well as help in our project if anyone is interested.

        To me, the fact that I don't have much advanced experience using Swing is actually another reason why I don't want to develop my whole infrastructure by directly coding with the Swing APIs, nor, for that matter, with the SWT APIs. Besides, I've been pretty disappointed with the quality of Swing user interfaces, so I don't want to be stuck with either Swing or SWT.

        You say that by abstracting the APIs, I would end up with very little functionality; but I don't see how that's a problem. Do you have an example of the kind of limitation I would get? My whole point is that I don't WANT to be coding the details of the presentation in the core part of my application. I want to be working with high-level objects that represent high-level concepts. That means of course, that for some applications, I may need to define custom (high-level) components, and provide an implementation for them in each of the chosen presentation technologies: but that's not a problem.

        In other words, each high-level control would represent a concept, without explicitly dictating what kind of controls should be used. Thus, as a simple example, an ActionPane component could be implemented in Swing as a JPanel with a list of JButtons, while in HTML, the same control could be rendered as a vertical table of either buttons or even simply links. As long as it fulfills basically the same high-level purpose, the business logic doesn't care how it's done.


        • #5
          Java isn't as focused on web as it seems. The following technologies are equality usefull in a webapp on a webserver as in a fat client with a webserver:
          - spring (both on client and server)
          - hibernate-annotations/EJB3 (server only)
          - acegi
          The following technologies are specific to fat clients:
          - spring-remoting
          - swing
          - webstart
          - spring-richclient
          Sun is also investing in java on the desktop: see the improvements for JDK 1.6 (such as no more gray rect, etc). IBM and Oracle too. It's just overshadowed by the enormous webapp community.

          If the quality of your Swing user interfaces is bad, it's 99,9% because you're using the wrong LookAndFeel (probably Sun's default...). Use the open source JGoodies Looks (or another good one): 5 lines of code.

          A problem with abstracting is for example when you're using JFormattedTextFields for bank account numbers, pop up menu's on list items, table sorting, ... It all needs to be abstracted and supported. It would be nice if it exists though


          • #6
            Abstraction => Lowest Common Denominator

            Originally posted by jonneve
            You say that by abstracting the APIs, I would end up with very little functionality; but I don't see how that's a problem. Do you have an example of the kind of limitation I would get?
            I thought something similar to ge0ffrey when I read your proposal to create this type of abstraction; you would suffer from what Rod Johnson calls the lowest-common-denominator (LCD) problem, whereby the only features in the abstraction layer would be those supported by all of the various implementations. For example, Swing has an expandable tree widget, whereas HTML does not. You therefore couldn't include the concept of a tree in the abstraction layer, because HTML wouldn't be able to implement it. Conversely, Swing doesn't have the concept of a hyperlink (AFAIK), so they're out too, which is a big blow to people using HTML! After weeding out all the non-common features of all the UI types you listed, you're not left with much.

            Anyway, that's the problem I envisaged, and maybe it's what ge0ffrey meant as well... but if you guys are smart enough to pull it off, the whole world will thank you!


            • #7
              Andrew, that's what I meant, you just explained it much a lot clearer


              • #8
                Why not make the lowest common denominator JSF?

                Why not make the lowest common denominator JSF? If JSF (which is extensible) was used as the engine to layout and tie events and navigation then basically what one would have to do is create JSF wrappers for spring components that correspond to the current core jsf components. Some integration work would have to be done of course because in Rich Client scenario there is no session etc but I believe JSF supports this sort of thing via overriding configurations. What are thoughts on this methodology...