Folks,
after a chat with Andrea, I have gathered enough courage to propose the
use of Apache Cocoon to develop the GeoServer administration UI and
related RESTful API.
As far as I inferred, the most stringent requirements for these
components are:
1) High degree of deployability: an UI extension should be just a JAR to
drop in the lib.
2) RESTful API interface.
3) High degree of flexibility when it comes to look&feel; in other
words, it should be easy to change the GeoServer skin to integrate the
administration UI into users' portals.
I18n and AJAX don't seem to be needed yet, but I presume they are not
far off in the wish list.
Can Cocoon meet these requirements ? I'm positive about it and I am
going to tell you why...
--O--
A long time in the making, Cocoon 2.2 is about to be out (RC2 has been
released in October 2007 and every bug seems to have been rooted out)
and it has redefined the way Cocoon is packaged, improving its modularity.
Actually, Cocoon 2.2 is:
1) Spring 2.0-based.
2) Block-structured. Every block is packaged as a JAR: drop it, restart
the container and you are ready to use it.
3) Blocks can call each other via the Servlet Service Framework, reusing
components and pipelines defined in other blocks.
4) Maven-based build system (it was painful when Cocoon switched to it,
but then improved considerably as Maven matured).
5) Sophisticated configuration options via cascading properties files.
6) Reloading classloader: change the Java source of a block and the
affected classes are reloaded without redeploy.
--O--
Now back to requirements, user interface:
1) Unlike Wicket, Cocoon Forms requires the developer to write down the
form model in XML and to use XSLT for fine-rendering of the view, and
leaves the choice of using either server-side Javascript or Java for the
controller (actually, I prefer server-side Javascript for simple "glue"
controllers).
2) Cocoon Forms uses Rhino with continuations (nor very RESTful, eh?),
hence, no problem when the user hits the "back" button in a frenzy.
3) AJAX is available via DoJo (basically, there is just a parameter to
set). This came in handy when I had to write an app that had to work
with AND without client-side Javascript support... no sweat.
4) Rendering is done via XSLT and is detached from both the XML form
model (which includes widget definitions and validity checks) and the
controller. This tiered approach means a lot of freedom to adapt the
markup to the desired look&feel.
--O--
The RESTful administration API:
I'd like to point out that Cocoon has a powerful URI-matching mechanism
(the sitemap), doing in a declarative manner what, for instance, Ruby
would do in code.
Of course, a truly ROA architecture implies stateless requests, hence a
"pure" AJAX client (no continuations, no sessions).
--O--
How much does Cocoon cost (in terms of JAR-tonnage and performance) ?
Well, performance depends on the task at hand, hence it is difficult to
gauge "in abstract". Though XSLT transformations are onerous, Cocoon
uses EHCache to avoid redundant transformations and some big websites
work quite smoothly using Cocoon.
JAR-tonnage is easier to gauge:
1) Most components are common to both GeoServer and Cocoon (Xalan,
Spring, Apache Commons, etc.).
2) 6.5MB are needed for Cocoon Core and Cocoon Forms blocks.
3) AJAX support comes with another 4.4MB (mainly DoJo stuff).
4) I18n adds another 3.1M (icu4j).
--O--
I've concluded my rant, which dealt only with technical matters though
the choice of a framework involves non-technical aspects as well.
I hope to have made my case clearly enough for you to properly assess
this humble proposal: if you need further clarifications, I'd be happy
to answer.
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------