Topic: Server Side

Making Vaadin, PureMVC and Grails Work Together

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

IT Mill Toolkit 5 out of Beta

itmill_logoWith 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.

A New ZK Tutorial

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: , ,

Echo3 Custom Components Coming into Focus

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:

  1. The client-side JavaScript components, extended from EchoApp.Component.
  2. Their corresponding client-side JavaScript synchronization peers, extended from EchoRender.ComponentSync, which deal with manipulating the DOM hierarchy.
  3. The corresponding server-side Java synchronization peers, extended from the convenience  nextapp.echo.webcontainer.AbstractComponentSync, which handles synchronization between the client-side and server-side component.
  4. The server-side Java 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.

Server-side Ajax Framework: IT Mill Toolkit 5, now with GWT

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).

Continue reading »

Topics: , , ,

ZK 3.0 RC Released

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.

  1. 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.
  2. 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 is enabled which allows you to update client’s information actively and the usage is simple and intuitive.
  • Add forward property of components to forward event without programming.
  • New expression of annotation is ease of use, and easy-to-read.
  • TreeModel is introduced which simplifies the job of Tree rendering.
  • Flash components allow you to play audio and video files. (including youtube clip)
  • Native namespace is implemented to speed up the performance while integration with HTML.
  • To speed up the performance of ZK, EL evaluator is pluggable, and a new way to render ZK components is introduced.
  • More integration with other frameworks, ZK has integrated with JSF, JSP, and Ext-JS.

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: , ,

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com