Home » Featured, Headline, Web Development

ExtJS, Metadata and GWT

6 April 2010 5 Comments
ExtJS, Metadata and GWT

Back around New Years I was looking for a way to simplify creation of cross-browser, DDA accessible HTML. Screens basically. They had to be very rich with lots of bells and whistles and they had to perform. Ideally this system had to be so simple to use that a non-technical person could create XBrowser, DDA compliant screens. I decided to take a second look at ExtJS and it has come a long way since I’d seen it last.

Using ExtJS you can create a screen programmatic-ally using classes and method calls but one of the neat features is that a screen can be entirely described declaratively in JSON notation. Declarative UI is nice, but a meta-data driven UI is nicer. I’ve created such systems in the past but always had to spend so much time maintaining the thing that interpreted the metadata (Sapient Powerbuilder Framework anyone???).

With ExtJS this could be avoided by just serializing the JSON into a database and back again. Eureka! I had a pretty nice metadata driven declarative UI with MINIMAL investment in “framework” code. Minimal investment in this type of “framework wrapper stuff” corresponds to a good upgrade path, quick time to market and very low likelihood that my “metadata wrapper” would break anything in the underlying ExtJS library.

Intrigued and not wanting to practice “architecture space exploration” [LINK] I wrote a proof of concept and built some screens out of metadata.

There was just one snag; ExtJS could paint the screen but in order to wire it to data it needed a bit of Javascript code to be written. With a complex screen this JS might grow to as much as 200-300 lines. Debugging JS with Firebug, Dynatrace etc. doesn’t scare me but it doesn’t sound good to an architecture review board either.

No good deed goes unpunished. It was mentioned that GWT could be used to write the same thing except instead of Javascript, developers could wire up their screens with Java code. The promise of Eclipse, PMD, FindBug and all that java-y goodness was just too much to argue against so I’ve spent the last few weeks in GWT hell and finally come full circle.

<rant>Just a second, hey, why did I do this? Well I like to know what I’m talking about. If I’m going to be responsible for something I want to know it’s going to work BEFORE we start. I don’t want to be an architecture astronaut who just reads the brochure. Everyone can read the brochure. I wouldn’t follow someone like that and I don’t expect my team to. </rant>

GWT (Google Web Toolkit) is essentially a compiler that takes your Java code and instead of byte code produces JavaScript. It does a nice job, traversing code paths so that only the bare minimum Javascript is sent down to the browser. It looks like a dogs dinner though.

Enter Ext GWT, Smart GWT (formerly GWT Ext) and MyGWT. Seems everyone has a GWT library, never a good sign imho.

GWT needs to know every execution path at compile time and hence it doesn’t support reflection. First problem was how to paint the screens from metadata. This can be achieved with GWT.create() but wiring the widgets to Java code with string literals is not possible.

In my use case, the developer should configure the metadata, the framework should paint the screen, the developer should write some Java code for screen logic, then wire the two together. There’ll be 300+ developers worldwide of varying experience levels so it’s gotta be simple to use.

I looked at Deferred Binding; “Deferred Binding is Google Web Toolkit’s answer to Java reflection.” BINGO!!! that’s got to be exactly what I’m looking for, it even says “reflection” on the box.

From http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html

One way to think of this is as “dynamic class-loading that occurs at compile time instead of execution time.” When the GWT Compiler compiles your Java application, it determines all the different “idiosyncrasies” that it must support, and generates a separate, tightly streamlined version of the application for that specific configuration. For example, it generates a different version of the application file for Firefox than it does for Opera.

reading on…

It’s probably pretty clear by now that Deferred Binding works a little differently than standard dynamic binding. Conceptually, though, the two concepts are fairly similar, and in practice all you usually need to do is just substitute a GWT method for a Java Reflection method. Instead of Class.forName(“MyClass”) you use GWT.create(MyClass).

So although Deferred Binding is the GWT’s answer to reflection, you cannot invoke a method using a string literal, you cannot create a class unless it’s known at compile time and you cannot hook up to an event without compile-time knowledge of the handler.

This makes metadata a pretty tough proposition. To add to the frustration, examples for Deferred Binding were so thin on the ground that it took me 2 evenings to get something working. I’ll post an example in the coming days to “pay it forward”.

Not to be outdone I looked at Generators. Again, no examples to be found anywhere, I’ll post one in a day or two. Generators basically let you generate java code at compile time, this code you never see but is then turned into Javascript. Honestly the GWT compiler must make 10 passes.

Generators could work. Using Generators would possibly allow the creation of a metadata UI framework however, it would take an enormous amount of fairly skilled coding to make this happen. They’d also be very brittle and tough to build; e.g. you have to write out java code using the GWT equivalent of a printf. You’ve no way of knowing if the code will run or not until it’s too late. Certainly very little chance of testing it. Rocket [LINK] claims to fix this problem but frankly this project is far too immature to be of any use.

Gwittir [LINK] is another option that claims to support Reflection. That’s dependent on GWTx and Google Gears. One of my pet-peeves about the open source world is all the dependencies. Don’t make me download 10 other things/frameworks just to draw HelloWorld. GGears is not an option for me so Gwittir is out.

Lastly, all these frameworks claim to optimize the Javascript, and they are true to that claim, HOWEVER, the third party libraries like SmartGWT, ExtGWT, etc. don’t optimize the widget Javascript. If you’re using SmartGWT’s grid, guess what, you’re downloading 500KB of widget JS.

So I’ve come full circle. For me, ExtJS seems like a good fit, easy to use, easy to drive off metadata and sure I have to write some Javascript but I’ll take a few lines of Javascript/Firebug over the mess that is Deferred Binding and Printf-style Code Generation anyday. Don’t knock it OR recommend it until you’ve tried it and fly safe.

5 Comments »

  • Chris said:

    Glad to see you still coding. It’s rare and some would say impractical in middle management though.
    =C

  • darrel said:

    GWT has always seemed crazy to me. Why use a statically typed language to write a dynamic language? Seems like you’ve already lost the game at that point.

    What you point out with the casting is the “problem” with statically typed languages like java. I don’t really have a solution for you, but if you are absolutely forced to, you could come up with a simpler domain language, and then write the tool in java/gwt to convert the domain language. But if you’re going to do that, you might as well use your json framework and avoid gwt altogether. I would lobby to cut out the gwt middleman if possible, because it is just going to add extra work.

  • Robert Cooper said:

    FWIW, Gears is a dependency only at compile time for Gwittir, as it is an option for the failover client storage API.

    And realistically, GWTx is only needed if you want to use the data binding system. If you just want property-based reflection, Gwittir doesn’t require either

  • Dave said:

    Interesting article, we’ve have just embarked down this path with EXT as well. We’re couple months in and we have the foundation a pretty descent framework including some graphical designer preview for component definition. I hear EXT 4 due out in the spring is going to enable all objects and components to be defined via xtypes which will aid in the definition manipulation and storage of the JSON metadata objects. Are you still developing this? How have you made out?

  • Francis (author) said:

    @Dave – we got a very advanced framework up and running very quickly with ExtJS. Ext GWT we got a basic framework up and running but it involved some rocket science – the problem was binding to events, I ended up using code generation to generate a Factory class which returned the correct instance of an event handler. It was very brittle.

    Anyway, ExtJS has improved even more since then and I would definitely recommend it. The nice thing now is that the same approach we had for generating Desktop browser screens could be used to generate Mobile screens with Sencha Touch. I have not come across any types which cannot be declared using xtype but I haven’t looked at it in a while.

    Both of these were prototypes but both were shelved for non technical reasons unfortunately. I would steer clear of all GWT solutions.

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.