GUI Component Architecture for Java Server Applications


News: GUI Component Architecture for Java Server Applications

  1. A new standardization effort has been started within the Java Community Process for the "creation of a GUI Component Architecture for Java Server Applications". According to the specification, it aims to unify efforts already undertaken in different independent projects, such as Jakarta Struts (there are scores of others).

    From the JSR homepage:
    The following 8 design goals represent the focus of this proposal:

    1.Create a standard GUI component framework which can be leveraged by development tools to make it easier for tool users to both create high quality GUIs and manage the GUI's connections to application behavior.

    2.Define a set of simple lightweight Java base classes for GUI components, component state, and input events. These classes will address GUI lifecycle issues, notably managing a component's persistent state for the lifetime of its page.

    3.Provide a set of common GUI components, including the standard HTML form input elements. These components will be derived from the simple set of base classes(outlined in #1) that can be used to define new components.

    4.Provide a JavaBeans model for dispatching events from client-side GUI controls to server-side application behavior.

    5.Define APIs for input validation, including support for client-side validation.

    6.Specify a model for internationalization and localization of the GUI.

    7.Automatic generation of appropriate output for the target client, taking into account all available client configuration data, such as browser version, etc.

    8.Automatic Generation of output containing required hooks for supporting accessibility, as defined by WAI.

    Visit the JSR homepage at:

    "This specification defines an architecture and APIs which simplify the creation and maintenance of Java Server application GUIs."
  2. This is really good news for Web Application developers. As we all know, building the client side gui's is more tedious and often more complex than building EJB apps. :) So far Servlets/JSP have provided us with the tools but not the 'direction' we need to create web applications.

    I wish this group luck, but I also forsee some problems. As Christian mentioned, there are numerous Web App. frameworks out there which all sprung out to provide workable solutions to Servlet/JSP development. This JSR, once developed would essentially 'deprecate' all of them. While this is good for developers (one framework based on the best practices from all the existing ones), it is not good for the existing framework initiatives, many of which are open source.

    This brings up a philosophical question: Should the spec provider just provide specs(JSP/Servlet), and allow other companies to innovate by providing value on these specs (Struts/WebWork), or should the spec provider provide both the specs and the frameworks?
  3. I think this is a good idea, and one that won't really deprecate the other efforts. It can be good because a large number of people will probably use it and thus there will be a large number of people skilled in that area, and it will leave most people with a good feeling because it is published by Sun, just like JSP is. It may also be good for large corporations that are leary of 'non-standard' technologies and techniques, as it may be harder for them to find people to support it in the future.

    On the flip side, there will always be those that don't want to walk the standard line. This has shown up in the JSP movement as well. There is Xml Template Pages by Resin, Xml Server Pages for Cocoon (another Apache project), Web Macro, and others that want a different way to do things. JSP is the standard and so most people use it, however they have choices out there if the need/desire is there.

    The trick though, IMHO, is to build a framework that traditional web developers will embrace, i.e. non-Java and non-OO people. This is what I think the biggest setback to Struts, WebWorks(?), and even the Pet Store example. They were designed and built by programmers, and it shows in the use of OO style implementations. I'm not saying it is bad, quite the contrary, but it may be hard for non-OO and non-Java people to grasp, not to mention tool support such as Dreamweaver, Homesite, etc.

    Robert McIntosh
    The Middleware Company
  4. I also dont think it is a bad thing to have sun sort out the GUI framework chaos that currently exists. I have been watching the scenery for almost 1 year now, looked into several of the existing frameworks, and read the very confident statements that accompany them. I think it is a good idea to finally get together, settle on something that makes sense to everyone (or most of us), and free our minds for some real work.

    BTW, one tool I have recently come to appreciate a lot is good old WebObjects (from Apple/Next). Not a J2EE thing at all, but they have a style of GUI programming that beats almost everything else, IMO. It sure has its drawbacks, as everything else, but I would be happy if some of those concepts would make their way into our new, all-encompassing framework standard..
  5. Much of Tapestry follows the kind of component based approach of WebObjects. Tapestry is a bit more structured, and makes a few trade-offs to support real scalability in a J2EE server ... and it's open source.
  6. I don't know, this seems like "too little, too late". As usual, Sun is in a reactive mode ... they've created JavaServer Pages (as a reaction to Microsoft's Active Server Pages) and aren't happy that so many people feel they are insufficient.

    Meanwhile, a number of alternative technologies, including work from the Apache group and others, such as my own Tapestry, have sprung up to fill the void. Suddenly, Sun is trying to get back in the driver's seat with yet another initiative.

    The problem is, JavaServer Pages aren't, and will never be, components. Components have state and an API and trying to stuff JSPs into a component model is ill concieved.
  7. Well, Sun did it with the Swing, did it not?

    So, why not try to repeat that success?

    Note: I am aware of the Swing's shortcomings, but it is decent and widely accepted framework IMO.

    Now, there is predisposition to the success in the server side direction. Just consider the following:
    1. Tool vendors just started to support JSP on the acceptable level.
    2. Alternative frameworks did not get wide acceptance and support of major vendors yet.
    3. There were enough attempts to solve the problem so Sun can learn from mistakes of the others and build on their successes.
    4. Expert group working on the project includes respectable companies and essential tool vendors (Borland, Documentum, Macromedia, WebGain and others).

  8. It's an interesting and good idea. I agree with what most people are saying here - Sun following rather than leading. JSP follows ASP, now servlet.ui follows ASP.NET.

  9. what a shameless plug!
  10. Interesting...this sounds almost exactly like what we're doing in Barracuda (, although we're not focusing exclusively on JSP, but rather aiming more at a servlets based approach that loads the templates as DOM objects.

    Barracuda provides:

    1. Robust server side event model (allowing server code to be notified when client actions occur) to provide Model 2 flow control. Requests are converted to event objects and then delivered to interested listeners.

    2. Lightweight server-side component framework modeled after Swing to provide strongly typed MVC interfaces to the DOM structures. Rather than manually manipulating DOMs you bind a component to a portion of the DOM and then just put data in the model. You can also add event listeners to components to be notified when a client-side event occurs (just like in Swing). Components include: BTemplate, BTable, BList, BSelect, BAction, BLink, BToggleButton, and BText.

    3. There's also a nifty little form mapping/validation framework, along with some default validators.

    4. Localization services to automatically localize property files

    The whole thing is in Beta 1 now, and already has lots of documentation/examples...

    Its nice to see Sun finally recognizing the need to move in this direction (and notice they've got Amy Fowler as lead! Amy was one of the lead designers on Swing, which seems to indicate Sun is serious about this and is allocating some real talent to the effort...)


  11. Sounds just like OOP's Hammock product:
  12. has been doing this for a couple of years.

    Also does WML etc, I've even seen a PDF look and feel from them.
  13. From "them" Robin? You fail to mention that you're the co-author. If you're going to use the post to promote youself at least be up front about it.

    I work at Sun and I know this JSR is only intended to provide a standard, not replace products like Swinglets or the other products I've seen mentioned on this site. In the end that will only help grow the market for products like yours when you adopt the standard in future releases.