skip to main |
skip to sidebar
More on the AJAX front - since all the previous posts, new frameworks have been popping up which can make life somewhat easier for producing professional intranet type applications more easily. Linking them all together was surprisingly easy, and allow for good separation of concerns ...
ExtJS is a very powerful JS framework, which comes with the most complete set of UI widgets out-of-the-box of any framework I've seen. There are also links with GWT, in the form of GXT (produced by the same company as the main framework), and Ext-GWT which was the original link, and continues as a result of the debate over the ExtJS licencing change moving from LGPL to GPL.
For our application, we've used the plain JS library, and written it as a single-page AJAX application (i.e. the browser only ever loads /index.html), along with our own JS classes to wrap up the business functionality, primarily panel-by-panel. More information on general ExtJS design principles can be found here. Specifically I would recommend a read of the Big Application, and Extending classes before you dive straight in, but there are many other good tutorials on the site.
DWR allows Java beans to be exposed straight to an HTML page as a Javascript object. At first glance, this sounds dangerous, but it's actually quite safe is a few precautions are taken. The developers of DWR have clearly thought about the security implications of such a framework, and you can easily protect yourself:
- Create an interface on your service bean, which only has the methods designed to be called from the UI. This is good practice anyway, but also prevents any accidental exposure of public methods on your service you didn't intend to expose.
- DWR forces you to name/mark all the beans you intend to serialize over to the JS object, including the ability to work with generics, or explicitly specify the collection types if not available.
- DWR works with Hibernate loaded objects, and specifically proxies, so that while you have to pre-load any lazy-loaded associations, it will only expose those associations that have actually been loaded. This saves both network bandwidth, and also information leakage if you don't actually want parts of the domain model exposed to the client.
- Used in conjunction with Spring, use Spring Security (formerly Acegi) to wrap authorization around the various service methods to ensure that only users authorized to call them can.
Note that DWR also takes care to try and skip a lot of the common AJAX security flaws, such as CSRF but one thing to bear in mind is that XSS is not protected by default (since you might actually want your application to send HTML + JS back to the server, if it was say a CMS ...)
Hibernate is still used as a persistence layer. In particular, with its support for externalised named queries, we can have our DAOs (or a base class) expose a query(String, Map<String, Object>) method, saving us bothering to put a new method for each and every query we want to allow, while only allowing the queries we want to. If you need to, you can also use Hibernate filtering to further restrict the queries at runtime based on the authenticated User for instance.
The Service can also provide a similar query(String, Map<String, Object>) which can delegate straight to the DAO (Careful! You will need to whitelist the named queries you actually need the UI to execute if there are other queries defined on your Hibernate session factory that you wouldn't want run ....)
This allows the UI (via DWR) to make Service.query(queryName, namedParameterMap) calls straight from the JS without having to implement individual query methods in the various components. All our data loaded into the UI is done via this mechanism, primarily so that we can mark everything as lazy-loading, and then use queries, along with the "fetch join" for each use-case to only load the data required for that particular user action.
Spring is used to tie all of these technologies together, configure all the various parts such as Hibernate and DWR. All the requests go through a Spring DispatcherServlet, which also allows us to link in the DWR controller and service URLs with some very small Spring MVC usage for index.html and a few admin/test pages.
Hopefully more (probably non AJAX) posts to follow without such a gap :D
Following on from the previous post, I've been trying to create some new GWT apps using that latest integration libraries, widgets and so on.
Previously there were some issues with trying to get GWT and Hibernate to play nice (Hibernate required Serializable, lazy-loading caused havoc, and there was manual work to map your objects), but a new library has been developed to semi-transparently map between Hibernate objects (complete with lazy-loading, etc) and objects capable of being serialized over the wire to GWT client apps. The only piece missing from here is a Spring interceptor to wrap around the service which would be able to transparently do this - I may have a crack at that myself.
So the list of libraries for my current GWT applications is:
- Spring - General application framework providing IoC, DI, AOP, and many other services for both general and web applications
- Hibernate - Generic ORM solution. Probably the best of the current crop - integrates as an EJB3 persistance provider as well.
- Google Web Toolkit - Browser client-side application development framework, including AJAX functionality
- Rocket-GWT - Lots of client-side GWT widgets here
- gwt-widget-server - Provides easy integration between Spring and GWT for the service layer functions
- Hiberate4GWT - Provides easy integration between your GWT POJOs and Hibernate POJOs
That about closes it off for the moment.
Oops! Almost a year has gone by - I think my desire to join the blogosphere wasn't as strong as I thought :). No matter ... time to report on further developments I guess.
GWT is now up to version 1.3.3, with a 1.4RC just around the corner, and has picked up quite a following. There are now a number of working applications, and more importantly websites, blogs and other sources if information on GWT. Some of the more popular ones for me are:- gwtPowered - a list of various different frameworks and other useful stuff
- rocket-gwt - a great component framework with lots of great UI widgets and functionality, like context menus, sliders, and replacements for some of the standard components.
- gwt-widget - another component site, but of particular interest is the GWT Server Library which allows standard Spring objects to be exposed as GWT services, without needing to explicitly tie that code in with the RemoteServiceServlet. This works by weaving code in dynamically using cglib's dynamic proxies.
- jwc-gwt-components - my GWT framework :) - this was written a while back and combines some of the features of the above toolkits. It's unique feature is that it provides widgets to integrate the TinyMCE and FCKEditor DHTML editors into GWT applications.
Personally, I think that the rocket UI implementations are probably better than the JWC or gwt-widget ones in most cases, while the gwt-widget server library method of weaving Spring components in is much cleaner than my copy-and-paste job of the code from the RemoteServiceServlet.
I still believe that it's silly to try and write a native GWT editor, especially as there are many decent editors out there that people already know how to use. Of course, they might give too much functionality, and can't necessarily be controlled as well from with GWT code.
Perhaps a refactor of JWC to focus the the GWT part of the project onto just the TinyMCE and FCKEditor support isn't such a bad idea, since most of the other parts of the framework are sown up elsewhere. Watch this space! - hopefully for less than another year!
Well I've finally joined much of the rest of the human race and decided to start a blog. As a record of things I've been playing with or interested by, the most recent thing would be the Google Web Toolkit. For those who haven't been reading any websites over the last few days, this is a toolkit for building web applications and websites that has been released by Google that's almost entirely AJAX based.
It allows you to write the UI for your browser pages in Java, using an API similar to SWT/Swing. Your Java code is then run through the GWT compiler which turns it into cross-browser compatible Javascript. A small HTML page contains links to your GWT application module, and the toolkit code takes care of the rest.
The toolkit has a built in test environment that also be coupled to Eclipse for debugging purposes, so you can step through any code that's proving troublesome, making it far more convenient than any Javascript debugger that I've seen (although the MS one is passable)
As far as licencing goes, it's pretty reasonable (IMHO!) - the provided runtime components, are Apache 2.0 licenced, while the compiler and development tools are closed-source and non-redistributable, but still free as in beer. Anything you create as output from the compiler is yours to licence and do with as you will, including commercial applications. In essence it's a free (beer) royalty-free development tool.
Having played with it for a few days now, it's definitely very cool, and something that will definitely take off. There's a lot of polishing to be done yet (not much in the way of component documentation), but it's already incredibly useful.
