Evan Summers's Blog

June 2008 Archives

A short history of Web UI programming

Web 1.0, XUL, Ajax, Laszlo, Flex and Silverlight have a common approach - declare the UI view using markup (HTML or XML), and use JavaScript to handle the UI events and manipulate the UI. JavaFX/Swing is a notable exception - which is exciting and/or risky?! 'Cos Web developers know and love JavaScript and HTML, so XML plus JavaScript is right up their alley.

If you're a Java UI programmer, there's GWT, Wicket and Echo. And with a great new Java plugin in the works, maybe Swing applets will be considered again in some quarters? But all web developers know JavaScript, and not necessarily Java, Groovy, et al, so probably JavaScript/Swing is a better bet than Java/Swing? Imagine having an XML schema for a flashy JavaFX/Swing toolkit, call it JavaFXml, with great JavaScript bindings, so make that JavaScriptFXml ;)

Anyway, let's look at the short history of web programming...

HTML, CGI, Perl
The Web started with HTML. HTML forms could be submitted via a submit button. Apache's Common Gateway Interface (CGI) enabled server-side scripts to process the form data, and generate an HTML result page. Perl, being a popular scripting language at the time eg. with Linux system administrators, suddenly became the popular language for CGI scripts, and many "sysadmins" suddenly became "webmasters."

JavaScript, DHTML
Netscape invents JavaScript for client-side UI scripting in web browsers, "designed to be easier for non-programmers to work with." Microsoft adopts it too for IE, calling it JScript. So it becomes the de facto standard - the lingua franca of web designers everywhere. HTML plus CSS plus DOM plus JavaScript equals "Dynamic HTML" (DHTML). Web designers suddenly become "web developers."

Java Applets
While certainly suitable for experienced programmers, this was not so great for "web designers," despite promising books such as "Teach Yourself Programming, Java, AWT and Swing in 24 hours." Actually this stuff is not "for Dummies." Not to mention some technical issues with the plugin like startup time, browser crashes, download size, etcetera. So web developers stick with JavaScript, which they know and love, to do neat DHTML things on the client-side.

PHP
Web developers know HTML, some JavaScript for client-side scripting, and some Perl for server-side CGI scripts. PHP gives them embedded server-scripting in their HTML pages. Poifect! Web developers become hard-code PHP programmers.

Java JSPs, Servlets
Schools started teaching Java, and enterprises got Java programmers, and we started spreading our Java love across the internets and intranets. But the majority of the web developers are not gonna suddenly jump off the PHP bandwagon and onto the server-side Java supertanker, notwithstanding the availability of the above-mentioned books - because 21 days is quite a long time.

Flash
Woohoo, let's add animations, interactivity and multimedia to spice up web pages!

XUL
Fantastic technology - XML UI markup plus JavaScript logic - way ahead of its time! If IE hadn't taken over the world and crushed Netscape, then maybe XUL would have taken over the Web?!

Ajax
Let's load content asynchronously, without having to submit and reload the whole page, and script the UI using JavaScript as per usual. Poifect!

Laszlo
Great stuff, inspired by Flash and XUL. If it was opensourced earlier, and/or bought by Adobe and renamed to Flex, or bought by Sun and renamed to JavaScriptFX...

Flex
Inspired by Laszlo, and currently taking over the RIA world, athough the Web is still owned by DHTML/Ajax.

Silverlight
Ditto.

JavaFX
Too early to tell. How is it gonna be better than Flex and Silverlight? What JavaFX tools for web designers?

Summary

Everything from HTML, through to XUL, Ajax, Laszlo, Flex and Silverlight, have a common approach, namely let's declare the UI view using markup (HTML or XML), and use JavaScript to handle the UI events and manipulate the UI.

Given the predilection of web developers towards JavaScript and XML, one wonders if the JavaFX initiative shouldn't have embraced JavaScript with an XML thingymajig also, like Microsoft (XAML) and Adobe (MXML) chose to do, rather than introducing a new scripting language? 'Cos in any event, the visual aspects of an UI should be designed by designers, using a GUI builder tool, rather than programmed by a programmer?

With a great new Java plugin in the works, and other JavaFX-induced improvements for client-side Java, maybe Java/Swing applets will be the preferred option for many of the Java programmers out there, rather than moving to one of the available scripting languages on the JVM eg. JavaScript, Groovy, JRuby, JPython, JavaFX Script?

If we want JavaFX/Swing to succeed in the browser, surely we need a GUI tool to design those flashy UIs, generate XML, and be scriptable using JavaScript first, and otherwise Groovy, Java et al, for programmers that prefer those other JVM languages.

Further Reading

Taking a cue from the cutting-edge of EJB3/Seam programming, last week i wrote an article titled "Gooey MVnC" proposing a convention-over-configuration MVC framework for Swing GUIs - to eliminate boilerplate and glue code for beans binding, events and tasks. Everytime i revise that article, i might write a new blog entry, like this one, just so that i can link to it again, which is precisely the reason why i was inspired to write this blog entry!

MVnC architecture for Swing GUIs

Rather than put our "application logic" in a "messy" view class, we create a separate "controller" class, with event handlers.

We wish this controller class to be as neat and tidy as possible eg. with minimal boilerplate or much else besides our application logic.

Let's explore how we might achieve this, using an annotation-driven application framework, with some AOP and convention-over-configuration.

Please submit your comments and suggestions for discussion below. This is an ideas-in-progress, without an implementation (yet). As such this article should be considered to be a first exploratory draft of a design-in-progress...

Next month, i'll whip up some kinda prototype, if it's deemed worth it, and if i'm still unemployed ie. with time on my hands.

Code Snippet

Our controller class includes annotations in order to enable our framework infrastructure to automatically map events from our GUI components to event handler methods, and to support background tasks and EDT-switching via AOP.

public class LoginController extends GBasicController {
   @View LoginView view = new LoginView(); // JPanel with components
   @FormBean User user = new User(); // for form fields auto binding
   ...
   @BackgroundTask void fetchUsers() throws DatabaseException {
      ... // long running task
   }

   @BackgroundTaskDone void fetchUsersDone() {
      ... // update GUI with results from task
   }

   @EventHandler void okActionPerformed() {
      ... // handle OK button pressed
   }
   
   @EventHander void usernameEntered() throw DataException {
      ... // validate username exists in database
      view.password.requestFocusInWindow();
   }
   ...   
}

Annotations in our model beans, eg. User, relate to binding and validation, where we wish to support automatic binding of view components to bean properties, eg. by matching component names to bean property names.

First Class Java: further thoughts on dot notation for class metadata

Who knows why i have a dislike for symbols like ->, => and even := ?! It's pathological, i know that, and i have an obsessive-compulsive (dis)order when it comes to code, and so be it.

So in the previous posting in this series of reports on my pointless coffee shop doodlings, i suggested the likes of username.property to refer to a PropertyDescriptor eg. for the purpose of toolable bindings, where by "toolable" i mean auto-completable, machine-verifiable and safely refactorable, using an IDE. If nothing else, this conforms to the current notation vis-a-vis .class eg. Person.class.

Now i'm thinking @person.username.property or $person.username.property don't look too bad, although many others suggest person#username of course, citing JavaDoc's notations, which i say is like the tail wagging the dog, but so be it.

So what's the big idea? Actually there is no big idea - only a small incremental idea, which is... Let's enable code that is fully toolable, refactorable, et cetera. Which means no references to properties in string literals eg. bind("username", ...). And code that still looks as nice and natural as possible, which to me means using the dot notation as far as possible eg. @company.contactPerson.displayName.

Let's imagine some code...

public class LoginController extends BasicController {
    LoginView view = new LoginView();
    LoginModel model = new LoginModel();

    public LoginController() {
        bind(view.usernameComponent, @model.username.property);
        ...
    }
    ...
}

where alternatively, the above might reference the java.reflection.Field literal as @view.usernameComponent.field.

This notation eg. @person.username.property actually represents a tuple of the instance plus the PropertyDescriptor, whereas @Person.username.property might literally be the PropertyDescriptor, from which we can get the declaring class ie. Person.class eg. via getReadMethod().getDeclaringClass().

Method's are a bit troublesome 'cos of overloading, in which case one might need to refer to their parameter signature to differentiate them eg. @view.load(Weapon, Ammo).method which i don't like the look of, but so be it.

Talking about methods, what about "first class methods", anonymous methods, closures or what-ever. Because people find anonymous classes a bit tedious, and many people are aggrieved that Java hasn't got closures like all other popular languages!?

My feeling at this minute is that if, like generics, closures can't be implemented simply, then they shouldn't be implemented at all, if the code examples look almost as unreadable as line noise!?

Anyway, now i must start working on my next blog entry, possibly to be entitled "Elucidating the MVNC™ Architecture for Gooey Tablets." Where "Gooey" is my codeword for "GUI" and "Tablets" are just tabbed "applets" - in a GUI container frame with a tabbed pane ala the spreadsheet metaphor. And MVNC™? Well that's an acrononym for "Messy View, Neat Controller, Trivial Model" which is just plain ol' MVC with some trivial guidelines and simple rules, as to what is messy and what is neat and what is trivial, so...

This work is licensed under a Creative Commons License.