Problems of being a large company, or why GWT and AppEngine don’t work well together

I wasted about a week on a known issue with GWT and AppEngine (link).  The basic problem is that GWT requires the source of a Java class in order to provide access to that class on the client side.  The issue is that age old problem of front end and back end version of objects that you encounter a lot.  The fix would be if the App Engine team had done some consultation with the GWT team so that this restriction of the GWT wouldn’t mean trouble for developers using both.  As it stands I’m going to use the light version of object solution.

Sucks that this problem exists, but, its what happens with a large company.  Two teams go off and do something and the results are a little incompatible.  It happens.

Google Web Toolkit

The big boys have another hit on there hands. If you haven’t heard the Google Web Toolkit is out in the wild and even comes with a nice Eclipse Plugin. The link is here (http://code.google.com/webtoolkit/). Very nice stuff and it even offers the ability to use the Google App Engine as host for your apps. The benefits of using GWT are plentiful, but, for my purposes:
1. Allows me to write a snappy looking Ajax enabled app without becoming a JQuery god.
2. Develop an app in a productive language like Java and then publish it as raw Javascript.
3. Eclipse plugin that enables me not to think about it.
4. Built in support for the Google App Engine (one less thing for me to think about).
5. Did I mention the whole Java thing…That is huge, because you are getting the power of Java in your apps.

XRX real world example

I know I have been mentioning my excitement about XRX and what it means for web development today. However, I have not gotten into any specifics as to why I think it is so powerful. Recently I solved a problem using XRX and I think its a good demonstration of the power.

I was building a little helper application and for a part of its
processing I need to store some web based data. Since it is pulling and storing data from the web XRX technologies are
a natural fit. I was working with Python since I was doing the initial design for a quick solution. I could have used a regular SQL database to store things. However, a few things bothered me about that:

  • Schema definition for something that I was actually changing a lot. I wasn’t big on firing up some sql management
    tool when what I really wanted was a web CRUD form that was flexible enough to change when my needs changed.
  • I needed to store web based data, so it was easier to store it as xml and to store it in a way that had columns of
    a typical web app (creation date, URI, etc).
  • I didn’t know where all the components were going to be and it made sense to have something that had a rest interface since I could easily access this from all sorts of connection points.
  • I had Orbeon running on my box so it made sense to use that to manage schema and my data.

Because of all these reasons I choose to create an xform model and form in Orbeon and then use the eXist rest interface
to update the model via HTTP puts in Python. Now I know that sounds like a mouthful, but, its actually much simpler than it sounds.

  • I created a form using the Orbeon Form Builder app. This is a web based app for creating xform web apps and models. You can literally create an app in 5 minutes using it. That app will have a data store automatically that has a rest interface. The power of this is that as I can change my model and web app in the same place. As I change it in the form
    builder its immediately accessible via Rest.
  • Once i defined my CRUD app, I was able to insert records based on the model from my python code using HTTP Puts. This was not even 10 lines of code to accomplish storing of data for my app with a flexible data model. I have worked on apps
    where it would take us 3 months to write code to allow such schema flexibility and such loose coupling. Using a REST interface is by the book loose coupling. If you have a unified XSD you could modify only one file to control data schema
    in all places.

Some of this may sound like overkill, but, keep in mind:

  • I’m not sure what my schema will look like yet.
  • Storing to a regular SQL data store would take 5 minutes, but, I would have to rewrite the code whenever the schema changes.
  • I didn’t need the CRUD web form, but, its an easy way to validate all my code by firing it up to see what my
    crawler (what I’m working on next) is inserting into the database.

Couple of kudos are in order:

  • Orbeon is brilliant.
  • Python is the quickest prototyping code that can be put into production
  • REST interfaces allow infinite customizability.
  • Sun Virtual Box is nice stuff.

A revolution of simplicity

I came across something today, that promises to change how I develop software moving forward.  Its not every day that you experience something like this.  The particular problem that I was looking into was for how to manage data collection and data quality reporting for a data management entity.  Having solved some problems for them with a different set of technologies (.Net and workflow technology), I was interested in what was the current state in the art (I had developed the core concepts of the solution over a year ago).  A technology of interest last year was Xforms.  There were several problems with using that last year.  Today many of those problems have disappeared so its viability is more promising.  However, while researching this I came across something much more consequential:  XRX:

X
Forms on the client
REST interfaces
and XQuery on the server

Stayed tuned to this space, but, I am expecting to add this concept to my toolset.  Meanwhile please review the manifesto of sorts:  XRX