Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
This is a pretty darn good list, it pretty much sums everything up. Just
to add my 2 cents about requirement 3. One thing to consider that would
allow us to relax this requirement, would instead make it extremely easy
to build and redeploy a new UI. Which brings us perhaps to another
requirement:
11) Decoupling the UI from the rest of GeoServer
I can see a couple of benefits. It could possibly reduce the download
size if we wanted to release the webapp separately. Which may be
something to consider once we have a good REST api.
Which may delay one more time the creation of the new UI, since today we
have no such a thing as a good REST api (afaik we have a sort of working
prototype? Haven't really checked it). Does TOPP think of investing
on it enough to have a usable one by the June code sprint?
The prototype is working pretty decently. I do think it's a possibility
that we would invest enough to have it usable by the code sprint, or
soon after.
A good REST API is actually my one major new requirement since the last
UI evaluation. Though I realize that the rest api can easily be
decoupled from the UI conversation, I think rest support in the UI
framework is one of my most important evaluation criteria. Or at least
to evaluate REST support and UI at the same time. One of the goals of
new configuration classes and new UI is to reduce the number of classes
one has to touch to add a new feature to GeoServer. If the UI framework
easily supports rest as a view of sorts then it could potentially be no
more additional work to add a new option to the rest api. If the UI and
rest framework are completely separate then that's another class that
one needs to touch to get an option 'fully' in GeoServer.
I would like to see the most common configuration tasks be handled in an
openlayers/ext based application, like uploading data and styling and
the like. These should just use the rest api. We still need the full
geoserver configuration UI, but I think it's not crazy to think that we
can handle a lot of the basic configuration through the map. See my
blog post at
http://cholmes.wordpress.com/2008/03/05/letting-everyone-remix-web-maps/
Then the GeoServer UI is more an option for 'advanced' users, who want
to tweak a lot more.
If we end up with a UI framework like wicket combined with a completely
separate REST API like Restlet that can be fine, but if something like
Struts 2 can handle much of the REST calls with a plug-in then that
might make less overall code, so it'd be easier for contributors to get
their heads around it.
Chris
Or perhaps users who
have a set data directory which does not really change do not have a
need for the UI? I would be interested in hearing feedback on this one.
I already have heard someone asking why we need an UI at all. This kind
of user loves to alter by hand the configuration files, so does not
really need a UI. Yet, this kind of user needs good documentation on
the file formats, and some stability guarantee, we haven't been able to
provide either so far.
(personally, if I was a user and GeoServer did not have a configuration
UI, I would not even bother to download it, so I represent the opposite
kind user, the one that does not really bothers about configuration
files and screams aloud every time he has to make a new SLD).
Anyways, back to the original point. Having a ui component that is easy
to build and deploy would allow developers to hack custom pages
directly, and not have to rebuild and redeploy the entire server. This
would probably be "good enough", and also relieve the requirement of a
truly pluggable or modular UI.
Hum, so you're proposing a UI made in some scripting language, such
as pure javascript or Groovy/Grails? Imho this would either:
* require dedicated UI people or
* raise the bar on the GeoServer developer, asking him to be a very
proficient java developer (otherwise he won't be able to do anything
with the gt2/gs API) and a good enough scripting language developer.
Both options scare me a little. Just yesterday I stopped working on
struts2 out of frustration because there is no tool support for
developing HTML pages with embedded freemarker directives and
struts2 tags (tool support == code completion, I'm not asking
for auto-documentation or refactoring).
How people can develop code without code completion
support these days is really beyond my comprehension ;)
Ok, end of rant. Just my opinion, if other people feel like going
down this road I'll endure the pain and try to adjust.
What other people think of the scripting option?
Or did I misunderstood it completely and you're thinking of something else?
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,47e8be85176341137850744!
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
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
