A New Java Forms Open Source Project

If we had a XUL implementation using Java for both the local actions and the remote objects. This should be combined with a good quality visual editor on the client side and a good documentation. There's also a requirement for the renderer itself to provide a good desktop look and feel integration and be very responsive.

Maybe we should look first to existing Java based XUL implementations.

Am in the initial phase of starting a (and what will be an open source) project that is something totally separate from this idea of an AJAX daemon Dashboard.

I wanted a rapid way to generate forms that are implemented in Java. So will take this HTML parser that I use (works very similar to an XML SAX parser) and have it generate equivalent Java Swing code. Here are the high-level features I have in mind:

• Support a subset of HTML (things it doesn't actively do anything with, the parser will skip over - HTML is too large of a specification to support handling in its entirety and for my purposes a subset will do fine)
  
  
• Will typically use the HTML output of visual web page design tools such as Dreamweaver, Golive, or FrontPage (the idea is to leverage such tools for rapid visual form creation and permit the form designer to specify form field validation via such high-level tools)
  
  
• Generate serialized Java objects as a resource to use to instantiate the form from at runtime (will be a binary resource file in the form's .jar archive)
  
  
• Translate any JavaScript validation into equivalent calls to Java methods of a Java-implemented validation library (which will be a standard library bundled as part of client application runtime)
  
  
• HTML events will be emulated via Swing events. Any named JavaScript event handler will be turned into an invocation of a Java-implemented event handler delegate.
  
  
• All displayable strings will be stripped out into a property resource bundle and use standard techniques to bind to this string resource bundle based on Java localization.
  
  
• All code that interacts with the form, say, event handlers, etc. will be generated into a separate Java class (or classes). The visual Swing code that is code generated and the form processing code that is custom written will be highly decoupled.
  
  
• The Spring Rich Client framework project intends to address form data binding so may look to incorporate support of Spring so as to leverage this (as Spring is an open source project).
  
  
• The means of client app i/o will now be anything that is permissible via J2SE Java class libraries. Will no longer be limited to just XmlHttpRequest. (In my case I would likely choose JMS as I like to build 100% pure SOA middle-tiers consisting of Message-Driven-Beans or MDBs, and usually build rich clients that run in context of an enterprise intranet or WAN. Someone doing something for the Internet might choose web services instead.)
  
  
• A given form will be packaged up into a .jar archive and delivered to clients from HTTP servers (probably being pulled down by processing logic of a forms engine built on top of Spring). Could also consider folding support for jBPM into such a forms engine on the client side. That's a JBoss JEMS product so it won't be anything intrinsic to this particular project - just something that could optionally folded in.
  
  
• Webstart would be the means of launching the forms application from the outset.
  

So that is an outline of what I have in mind so far. No support of XUL because this concept is ultimately a pure Java Swing application. Once one is using Java at all then why bother muddying waters with other native compiled binaries such as the requisite XUL runtime components?

My concept does leverage HTML and one could see that it would be possible to use this approach to turn out both a Java Swing rich client as well as an HTML web app version. If the HTML web app were AJAX, then the very same SOA middle-tier could support both. And there would be no hugely complex and mind numbing MVC framework to code to on the server-side. Consequently overall development would be an order of magnitude easier.