This page last changed on Mar 15, 2007 by bowens.
UI as it stands now is based on Struts/JSP approach.
This has proven to be troublesome maintainance wise, and does not follow suit with our modularization approach.
A new user interface technology must be able to satisfy the following requirements (R, requirements):
- No 1.5 feature dependence (no annotations, generics and the like), Geoserver is a jdk 1.4 application.
- Every module UI should be defined in the same module, following the principle that dropping in a new jar bring up both new functinality and new user interface to configure and use it.
- Easy to learn, or at least easy enough to allow modifications to existing UI without too much pain.
- Easy to deal with, define one template, one class and be done with it, no fancy external configuration files, no bean form classes. Convention over configuration and simple minded please.
- Open source.
- Well supported, and with a good probability to still be around in a few years.
- Lively community behind it.
- Easy to debug, either the framework does not need anything else beyond a standard java debugger, or the tool to debug it is widely available (there's at least an Eclipse plugin for it).
- Tool supported, which means, either real tools, or so plain easy that HTML/XML and java editor capabilites are enough to develop with it.
- Easy to modify and test. Currently it takes a while to clean and build the web module, only to test a simple change to the UI. You should be able to change the basic layout or HTML without having to build everything.
Ideally, we would like the following too (W, wishes):
- Everything defining the user interface should be stored in the classpath, so that build system does not need to be modified in order to deal with the UI framework. This is in particular true for static resources: they must be stored in the classpath as well.
- Decent documentation and/or books describing it.
- Easy to add AJAX tricks to it in order to build a highly interactive UI.
- Only need the JRE to run. Struts currently requires JDK, and it'd be very nice if it was lighter weight.
A few use cases
- Jeanne is developing a WFS extension that requires minor modifications to the configuration and, as a result, to the UI.
Jeanne jumps to the WFS module, modifies the configuration, and then reads a little about the UI framework, looks at the existing UI and performs the small change. This should be easy enough that no real knowledge of the UI framework shall be needed, just "monkey see monkey do" approach. Which means, the base module UI shall be coded to be as straightforward as possible, not only as a working tool, but also alike a learning tool as well.
- Joe is in charge of developing a fully new module to support the next WxS service.
He develops the real functionality and its configuration, then needs to add the user interface for it.
He reads some introductory documentation, skims thru the frameworks documentation or book, and looks at the already implemented WMS/WFS user interfaces. He just declares a few extensions to known extension points in the Spring context, adds a dependency to the web module so that his own is added to the classpath, and the new config, demo and sample requests are added to the user interface.
- Adrian wants to add some extra ease of use, by adding a new map building module.
The module does not really brings in new base functionality, just builds on top of it and allows for increased ease of use. Lots of static resources are used, no real server side functionality is added.
He just builds is own module with standard tools, declares an extension in the Spring context, and drops the outcome of its work in the resource section of a module, adds the dependency in the Geoserver web module. All static resources are served as if they were included in the web module itself.
An evaluation of existing frameworks
This is what we want to drop. Does not respect most of the requirements we did set, in particular the usage of JSP prevents real modulization, and there are way too many extra configuration and classes to write (tiles, struts configs, form beans, ...)
JSF out of the box is based on JSP and configuration files, so it's out of question. Yet, facelets allows for pure XHTML templates and integrated layout management, and the JSF configuration subsystem is modular, allowing to build a convention over configuration one instead of the XML based one.
Books are there, as well as IDE support, and of course it being a standard is a plus.
So, theoretically this could be a solution, but no one has really investigated it at the moment.
Webwork is probably the most promising non component based framework out there. Views can be built with velocity or freemarker, and has built in support for serving static resources out of the classpath, books are there, as well as tools to support velocity and freemarker page building.
Standard configuration is declared in a separate XML file, thought it's possible to use a convention over configuration approach replacing the standard configuration subsystem, following the inspiration provided by project Able (you'll need an old checkout of the project, apparently now they removed webwork dependencies and moved onto Stripes instead), and replacing the widely used annotations with some other declarative mean (Spring context, static fields inspected by reflection, whatever...)
The downsides here is that we would need to cook our configuration solution and support it by ourselves.
Also, non component based is definitely closer to HTML, but at the same time way less powerful than component based (just to give you an idea, one has to read 500 pages of a Webwork book to be able and build the same pages that can be built with a component based framework after 200 pages of book reading...). The upside is of course that no abstraction means no abstraction leakages as well.
Wicket is a component based framework using pure XHTML template and with a strong java classes orientation: in wicket every page is a java object. Tools are available and building a simple interface seems straighforward.
Documentation on the site is poor, but there are examples and a book is available as well.
A sample modular UI has already been built, and can be found in the community Geoserver section here.
In detail, this solution satisfies R1, R2, R3 (more or less), R4, R5, R6, R7, R8, R9, as well as W1, W2, W3, W4.
There are downsides thought:
- the paradigm shift is relatively big, and sometimes writing the sample modular application I've found myself fighting the framework instead of using it, because it forces you to think components and forget basic HTML interactions (links are particularly strange, in that they act just like buttons, not like links...).
- while it's possible to serve static resources associated to wicket components stored in the classpath, it's not really possible to serve static pages out of it. A simple servlet should be coded to provide access to in-classpath resources (not much of an issue in fact)
You can read a bit more about Wicket here and see some examples.
Here is a useful article to read about Wicket: Wicket Impressions
Able switching to Stripes made me consider that one too, but it's heavily dependendent on JDK 1.5 features, so it's out of question for the moment.
Google Web Toolkit (GWT)
There is a detailed write-up here.
Can we please be sure to consider internationalization support as well.
Posted by jive at Jan 02, 2007 13:12
There is a WYSIWYG ide for Google Web Toolkit that simplifies a lot of the develpment (at least for making user interfaces and RPC) and is called VistaFei. It has a community version which is free for use and can be found in
Someone implemented a wrapper for the google maps api in gwt and I guess it should be great to implement mapbuilder under gwtk or ways to integrate mapbuilder with gwtk.
Alfredo J. Perez
Posted by ajperez4 at Apr 27, 2007 12:23