Webification Project

I am more and more fond of the Dojo idea. But since Mahesh wanted to try out Echo2 and it is a good learning excercise for us to look at that code (perhaps you check it all into the "gwttest" svn directory for now, plus, if you could, put your GWT test code in there as well. No, we won't continue with GWT, but the question will come up: why didn't you use GWT? And then just showing this mumbo-jumbo-code will help settle the discussion.

Since Santosh's intriguing question 1, "why can't we do 3-Tier with SWT?", I can see a nice way of dividing up the work which may lead to not one but two ways to making a 3-Tier application and we won't loose lots of time over it.

Dividing Up the Work

We can divide up the work nicely between Mahesh and Santosh into two parallel work items. There will be (1) Dojo work to get the widgets just right. There will be the (2) surgery on the framework to split two tiers into three.

Dojo Work: XSLT to Dojo Widgets

Make a transform like our swt.xsl but dojo.xsl, that transforms our view definitions to dojo objects. That can be done without much infrastructure at all, just write the XSLT to transform. I'm not sure how experienced you are at XSLT, and because I am a great believer in XSLT and I believe in the power of the right style and approach to XSLT, I am directing you to my tutorial that teaches XSLT "the right way" ;).

http://aurora.regenstrief.org/svn/XSLT-Course/trunk/ it's got tons of examples and a slideshow to explain all that stuff:

http://aurora.regenstrief.org/svn/XSLT-Course/trunk/tutorial.ppt

The swt.xsl, and swt.xml + xsltgui.xsl in xwsf/gui are also guidance to what is in scope and how about we're doing it. BTW, it isn't used here, probably, but swt.xml is transformed by xsltgui.xsl to make swt.xsl, which is what turns our view xmls into actions. Now we make a dojo.xsl which will turn our views into dojo XHTML.

Framework Surgery: Splitting Two Tiers into Three

Split the 2-tier framework into 3-tiers. The UserInterfaceThread? related (3) UI part and the ApplicationThread? related connector framework (2). This involves some refactoring, but it is not going to be a complete rewrite.

  1. Wherever we schedule Runnables, we must instead make API calls.
  2. Then use remote API calls (e.g. RMI if it's easy) to host the the ApplicationThread? and the UserInterfaceThread? on different Java VMs.
  3. Replace RMI with XML based data.

The UserInterfaceThread? starts out in ViewFactory?. There's a special method to bootstrap the application. That would be the main method of this browser. It would connect to a server.

We use "dialog viewports" as a channel for the application to push UserInterface? material to the user. So, the UI component basically only connects to the ApplicationThread? server and offering a dialog viewport channel. The application thread server will then spawn a new ApplicationRuntime? thread, and will present the application runtime perspective with the login button. The sub-perspectives can open more viewport channels. We already have 2 viewports but we will make more, e.g., a list toolbox viewport, etc.

A viewport right now is basically an Observable List where the ApplicationThread? can stick a ViewStuff?. ViewStuff? is like instant-soup, you just add water to get it real. The ViewStuff? is a reference to the view XML (URL) and the application objects that should be accessed by the view. In a remote scenario, the application objects become handles (id), which can then be referred to by the view to ask for data (the <data> tags do that.) ViewPorts? are created

Pushing the button mediates an action through the controllers by sending a message. We have these Actions pretty well managed already. Any other UI events would be handled in the UI thread and sometimes call the ApplicationThread? back. It does this through the ApplicationContext? object. The ApplicationContext? object exists paired in both JVMs/Threads and it is the UI's handle on the Application. Our mw system has the ApplicationAct? which implements xwsf/gui's ApplicationContext?, so it's already clean. The ApplicationAct? on the server is represented by a server thread.

It's vert clear already how the application splits into these two pieces.

I think going through the RIM step might allow the refactoring to happen without introducing any other complexity such as XML rendering of communication messages. That can happen later. In that last step, we will mediate the communications through XML messages. And I am considering using again XSLT for that. The xwsf framework has (and started out with!) the GSTServer, which is an XSLT based active server pages Servlet. I had implemented AJAX like functionality with this even 5 years ago with this, so I know it works and I like to reuse it because it is simple and XSLT is so well designed. There would be a few messages and the session and other ApplicationContext? info goes by the ApplicationContext? handle (id). Then on the server the events are dispatched to the right ApplicationContext? object (each running in its own Thread.)

Conclusion

You see, these 2 work items are parallel. There will be (1) Dojo work to get the widgets just right. There will be the (2) surgery on the framework to split two tiers into three. Both are independent. They come together at the final stage once the work item (2) has impemented XML messages. Then we can simply replace the UI component with the browser and Dojo. The very, very nice thing about it is that at the same time, at about no cost, we have an SWT based application browser and Santosh's idea of the 3-tiers without web- browser has become real.

Because I can see so clearly how our framework dissects into these pieces I am less eager now to go the Echo2 route.