HumbleBlogger

Wednesday, October 05, 2005

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.

3 Comments:

  • This idea is very interesting. I see that this entry is from October, have you gotten any traction?

    By Blogger Simon Peter, at 12:17 PM  

  • No, I've just spent some time looking at the various HTML parsers and javacc as the HTML parser I used before is under the GPL and I don't want to use any library that is GPL, as this might be for a project that is incorporated into my company's products. So any open source software I incorporate into this forms system would itself need to be free market friendly to private enterprise.

    Also, I'm torn between this concept for a forms system and the AJAX siren. I've got another idea which is to build a Java NIO-implemented AJAX-to-JMS bridge. In which case would go with AJAX-style forms application that does full blown JMS messaging. Here's a link where I describe that idea:

    AJAX-to-JMS bridge

    The messaging bridge would be the simpler project to implement. But need to conduct some prototyping to see if HMTL-based forms could be made to operate fast enough for our data entry users. I know the java forms approach will work for sure based on existing systems in current use.

    By Blogger rogerv, at 11:54 PM  

  • Oh, have evoled thinking regarding the java forms concept in one respect. On account that Sun is folding the Rhino JavaScript engine into Mustang release of Java, am thinking that JavaScript on the original HTML web page could be preserved and executed using Rhino. Hence, say, FrontPage might generate some JavaScript for field validation, and that script would just get executed at runtime via Rhino. Wouldn't want to replicate DHTML APIs, though, so there would be definite limits as to what one might could do in JavaScript and have it translate or be preserved as is.

    By Blogger rogerv, at 12:08 AM  

Post a Comment

<< Home