Apologies for not being all up on this thread, hopefully soon I'll find
some time to sit down and digest it all. But I wanted to throw out a
thought on UI.
Instead of picking a full blown UI framework we could consider just
using a template language, like freemarker, to provide the UI through
restlet directly. Instead of having a separate and parallel
architecture, component like wicket or mvc like struts/spring, where
we'll be replicating objects, we'd just have html templated output from
the rest api. One of my biggest goals with ui switch over is to make it
so we write less code when we add new options. If we are making rest a
first class priority (which I strongly think we should), then a UI is
basically the same makes a lot of sense.
I had been a bit hesitant on this, but a few things are starting to
convince me. First, that's how most all the other languages do it - in
python everyone just uses a template language for the web tier. You can
swap them in and out, there's just not so much the concept that you have
a full framework that handles all UI. Second is I talked to one of the
co-spec authors of JAX-RS who works on Jersey -
https://jersey.dev.java.net/ Think restlet but annotation driven
instead of coding routers. He said that Hudson, our build tool, was
done in that way - rest style, and they used jelly for the template
language. And it's UI looks pretty good. We just need a designer to
come up with the UI, but we have a couple good ones at TOPP.
It'll take work to get it looking really nice, but an advantage I see is
that plugins can just make a rest api and do really simple html forms
for editing their config. Then later someone can make the template
nicer, ect.
There obviously are some open questions in this approach, like what is
lacking versus the full blown UI technologies - things like
internationalization, ect. But I think we should do our UI technology
evaluation hand in hand with our rest stuff.
Jody Garnett wrote:
So in Tuesday's meeting we figured out the scope for Geoserver 1.7,
renaming this subject line to match ...
Andrea Aime wrote:
The "eat your own dog food" argument is good, but I expect the REST
api to have its own battery of unit and functional tests (my position
atm is to vote -1 for any community module that tries to graduate
without a decent testing coverage).
The idea that we have to rely on a UI managed by a different group of
developers strikes me as odd and risky thought.
Thanks for expressing my concern so clearly Andrea, I think a good way
to proceed is ...
1. Set up a user interface, wicket was the last man standing that met
the requirements I was interested in
2. Use the user interface to hammer out the configuration layer
3. Start to roll out only the methods we love in the configuration layer
via the REST API so external scripts can be written
The alternative, making a JavaScript user interface would involve making
a lot of REST API for functionality that is already captured by GeoTools
DataStoreFactory ... and I am not sure where such a quest would end?
Would we by extension get a REST API that covers 30% of GeoTools? Scary ....
Making a separate war, implemented in Java or Groovy I guess, is also an
option; even for low level services like sharing DataStores we could
register a few shared services using JNDI and let the user interface WAR
have access to the running GeoServer.
I cannot quite remember what the attraction to Groovy was? ie why was it
floated around as part of the user interface discussion?
Jody
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,48232a47179241012714783!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
