-
Get a monthly update on best practices for delivering successful software.
On seeing that someone had developed a Grails Plugin for Vaadin (the former ITMill Toolkit, based on GWT as a front end technology), I immediately grabbed it and started exploring. One of the first things I do when developing things that look like GUI's is apply PureMVC to it. It's sort of like a big MVC switchboard that lets you hook together the smaller MVC's of whatever framework you're using. Overkill for really simple applications. Crucial for big ones.
Building a PureMVC app was pretty quick, but I ran into a small problem. Since PureMVC Multicore uses a Multiton pattern (essentially a map of Singletons), when Grails recompiles and restarts on code changes, the application barfs with a "Facade already constructed" runtime error. The solution is simple. In your subclassed org.puremvc.java.multicore.patterns.facade.Facade, change the following:
public static ApplicationFacade getInstance() { if (instance == null) { instance = new ApplicationFacade(CORE) } return instance }
to this:
public static ApplicationFacade getInstance() { if (instance == null) { // nuke the multiton so we can do the grails recompile if (ApplicationFacade.hasCore(CORE)) { ApplicationFacade.removeCore(CORE) } instance = new ApplicationFacade(CORE) } return instance }
And voila, your app now recompiles and runs without a hitch, just like a Grails app should. (CORE is a string constant to name your core.)
Related Services: Java Application Development, Custom Software Development
Topics: Ajax Frameworks, Google Web Toolkit, Grails, GWT, IT M, IT Mill Toolkit, PureMVC, Server Side, Vaadin
With the release of IT Mill Toolkit 5.3.0, the server-side RIA framework is now ready for production. I announced the initial release of 5.0 back in December of 2007. Since that time, IT Mill 5 has gone through several revisions and the release of GWT 1.5 (which means you can use Java 5 now on both the client and the server). As a reminder, server-side RIA frameworks let you write your app completely in the server and uses a client-side Ajax engine to render the interface. The nice wrinkle with IT Mill is that both the server side and the client side are written in Java, so if you want to add a component, you don't have to break out the JavaScript (see the extensive and high quality reference manual for details on how to develop your own custom components in GWT). If you're a Java shop, that's got to be a good thing.
Topics: Ajax Development, Ajax Frameworks, GWT, IT Mill Toolkit, Java, Server Side
There are already quite a few tutorials and mini talks on the ZK site, but one more never hurt. Over at Dr. Dobb's, Andrzej Sekula guides you through "Hello, World!" with ZK, while explaining architecture, features and few other things. Worth a look.
Technorati Tags: ajax, zk, tutorial
Topics: Ajax Frameworks, Server Side, Tutorials, ZK
I had a read of some of the Echo3 developer docs this weekend. In particular, the docs on how to create a custom component were very interesting. If you've read the custom component docs for Echo2, you know how messy that was. This time around it looks a little cleaner. There are basically three different object hierarchies:
EchoApp.Component.EchoRender.ComponentSync, which deal with manipulating the DOM hierarchy.nextapp.echo.webcontainer.AbstractComponentSync, which handles synchronization between the client-side and server-side component.
The docs aren't quite done yet, but already it looks as if component writers can leverage the framework much more than in Echo2. It's good to see that event handler hygiene is encouraged in the docs.
Powered by ScribeFire.
Topics: Ajax Frameworks, Echo3, Server Side
I've long been a proponent of server-side Ajax frameworks -- frameworks that store state on the server and use an Ajax engine in the browser to drive the display. The advantages: state and control logic stay on the server, so security compromises that exploit client-side state and logic are more difficult to pull off; developers can work in one language and, for the most part, ignore the fact they are writing a web application. The disadvantages: the server retains a large amount of state, so scaling your application can be problematic.
There's one other large disadvantage to these open source server-side frameworks: for every 100 Java developers who use the framework, there is only 1 of them that can do serious JavaScript development. That means that the lifeblood of these frameworks -- the development of new and cool JavaScript widgets -- is sluggish at best. That has certainly been the case with the best known 3 frameworks: Echo2, ZK and ThinWire (though ZK does wrap a number of Ajax widget libraries, such as Dojo).
Topics: Echo2, GWT, Server Side, ZK
One of the enduring criticisms of ZK, the server-side Ajax framework, has been against its perceived slow performance. Critics have observed, and supporters have conceded, that applications written with ZK seem a touch slow. So it's no surprise that a major focus of the latest major release has been improved performance. The ZK team found two major bottlenecks in performance testing:
After a series of stress test and reviewing the kernel code, we found out 2 bottlenecks on ZK 2.4.1 and fixed them in ZK 3.0 RC.
- The executing time is too expensive when rendering components. ZK uses templates to render components, and the EL is generally used in templates to simplify the variable access and templete maintenance. However, when the concurrent access rises to a large number, the overhead on rendering component with EL is too heavy.
- Threads spend too much time on waiting the synchronization when many threads access to the same cache under current cache mechanism.
ZK 3.0 RC solves these 2 bottlenecks by using the renderer class and new cache mechanism. The test result shows ZK 3.0 RC is four ~ five times faster than ZK 2.4.1.
I haven't validated these performance figures myself, but an initial comparison between some demo applications confirms a much more responsive user experience.
ZK 3.0 RC has also added a number of other new features:
Server push was already supported in ZK through use of the timer component, but the enhancements make it even easier (note: we're not talking comet, but rather client polling). Even more exciting for me is the dynamic loading of ZUML (the XML-based markup language for specifying ZK interfaces) pages dynamically from sources such as a database. That's very helpful if you want to allow non-developers to deploy interface changes without having to spit out ear or war files.
As usual, the ZK folks have done a good job documenting the changes and additions. It's too early to tell if 3.0 will solve all of ZK's previous shortcomings, but ZK is well on it's way to becoming my favorite server-side framework.
Technorati Tags: ajax, zk, announcement
Topics: Ajax Frameworks, Announcement, Server Side, ZK