After spending some time now using the ThinWire RIA platform I can honestly say it is definitely a mature and powerful tool for building web applications that require complex user interface features. While my test application still does not extensively test every feature one may require, it shows ThinWire is a highly viable candidate for developing business applications.

Additionally this has been a useful learning experience from my personal point of view, as a good example of deploying an EAR (Enterprise Archive) carrying a distributed system using sophisticated persistence architecture.

The platform makes producing an application from scratch relatively effortless. There is some initial set-up involved – including removing the Mac files and folders from the ThinWire installation if you’re using Windows (there must have been a better way than the route I took which was to manually delete every one). But I found creating a buildable and deployable application, with an associated Eclipse project, was a very rapid process. The sample applications are fairly sensibly structured in order to give you a very good idea as to an appropriate development pattern to follow.

I now have an application in a healthy enough state to start testing things like persistence of entities to and from a database. It will be interesting to see if there are any behavior quirks due to the design pattern of the platform or if, as claimed, it really can cope with any Java feature you would wish to integrate into your user interface.

Some nice things that you get include a ready to start apache tomcat application server, but also more usefully an apache ant build script for both example applications.

The build script is an excellent addition for any developer looking to rapidly develop deployable and fully functional applications. As far as I can see from examining this script and building my own test app out of it the build and deployment procedure is one of the most straightforward I have come across for an AJAX / RIA platform.

I strongly recommend developer who has never used an apache ant build script to develop and deploy their applications to look into it for future applications they may develop. IDE based deployment tools can only go so far to helping you develop and implement a web application.

So in relatively simple terms an RIA is essentially just a web site transformed into a more complex web application through use of many common application user interface features such as trees, lists, calendar date pickers etc. But AJAX is a term used to describe the technology behind many of the original platforms that provide these rich user interfaces – Asynchronous JavaScript And XML. My problem here is with the XML part of the acronym as many of the newer platforms, to my knowledge ThinWire included, don’t actually directly manipulate XML in the user interface. Or at least its not part of the core functionality of the RIAs mechanism of operating. Sure you might be able to do stuff with XML data within the confines of the platform, but then you can also do stuff with many other data formats too and it would be nonsensical to list all these in an acronym describing the nature of how the RIA actually works.

Of course dropping the AX leaves ‘AJ’ which is not as audibly pleasing a word. AJ also could be prey to a similar fate as the XML in an (unlikely but possible) shift away from JavaScript as a browser language, and additionally a term describing that browser language says little about what it is used for anyway. I am coming round to the idea of calling such things RIA platforms instead to describe any kind of technology which might lie beneath a Rich Internet Application. As there are so many RIA platforms out there with many different modes of operation this seems like the logical solution.

What ThinWire does is push everything out to the server side code, which is written entirely in Java. There is no conversion of Java into JavaScript, the view the user gets is simply handled entirely by some server side code. This seems to me not a terrible model as your user interface can still be contained in a separate .jar than the main application logic to stop the wrong code bleeding into both. Additionally one can presumably use all features of the Java language as the UI components are simply Java classes all the way through. There seems to be a reasonably extensive library of visual components. Like GWT-Ext the UIs created with the ThinWire AJAX platform are event-based. The only downside seems to be that the project hasn’t been updated with new features for sometime, though bug fixes appear to still be being released.

Still if the whole package is essentially all Java, there shouldn’t be anything stopping a user extending the thing themselves for their own purposes. The key ’selling’ point of it is the pushing of the code responsible for the client side view out to the server.

While I don’t have the time to cover many of the issues relating to general usage of the API, from time to time I hope to post some useful information about it. Using GWT and the extension is a learning curve as it has some foibles and a unique deployment procedure to be aware of, but I’ve very much warmed to it as a tool in web user interface development.

So the issue at hand – a null pointer, which will not be picked up until run time and you will only see if you explicitly look at the javascript errors when browsing to your page. If you have unusual behaviour of a component or panel where it is not displaying, check your browsers javascript errors for complaints about null pointers.

The cause – very often simply that you declared something and tried to use it without first instantiating it.

E.g.

Panel otherpanel;
Panel panel;
panel.setTitle(“Hello mate”);
otherpanel = new Panel();   <– you instantiated this one here, but not the other one
otherpanel.add(panel);

Here ‘panel’ has not been instantiated before it is used, a simple but easy to miss error especially and it is not always picked up by the IDE and java compiler.

So check if you’re trying to use something without being instantiated first, before you start tearing your hair out about why its not working!

the styling interface

The data entry interface for the menubuilding app

I’ve gradually been developing my menu building application into a distributed web system. It uses OpenLaszlo for the building front-end, java & jsps for the database storage and retrieval facilities and OpenLaszlo to correctly display the menu from provided settings.

Here’s a few screenshots to spice up this at times rather bland blog!

Some nice features to note:

• dynamic data entry facility with ability to add and remove data as desired (I’d hope to standadise it into a generic ‘data entry’ class so it can be reused under different circumstances).
• color swatch components with preset colors to select as well as RGB color pickers
• dynamic example that updates as styling options are chosen

Plus, while I can’t easily show it, there’s a little bit of animation involved too.