Ok, cool. Yeah, that was my fear with it, but then I saw that Hudson's
user interface looked pretty nice. But it looks like you've already
done a pretty full evaluation. Oh well, it was a nice dream to have for
a bit :)
Chris
Andrea Aime wrote:
Chris Holmes ha scritto:
...
Ok, I don't want to dictate technology choices at all, since I won't
be working with the codebase. But I do want REST as a first class
citizen, in some ways even more so than the UI. So from my
perspective it seems like having a technology that can handle both
would reduce the amount of code overhead of adding new options.
From a product stand point, what I'm currently thinking is to have a
pure javascript, map driven interface that will allow much more
intuitive configuration of GeoServer. Not the full configuration,
but the 20% that 80% of people will want to do - upload shapefile,
pick the keywords and meta information, style the sld, turn
geowebcache on, stick on google maps or google earth. This will all
use the rest api.
I do agree that on the java side we don't want to rely on external
developers - we don't want to make potential contributors learn
javascript so they can configure their service. But it likely is
going to get less investment. From my perspective I want a java gui
that's really easy to add new options to, but it doesn't need to do
non-trivial configuration. I'm also leery of picking a framework
based on anticipated needs, like 'complex mapping', as we've been
hearing about that for years and it still hasn't come. It's a very
advanced thing to just get right on the code, and I'm not convinced
that funding for a real configuration GUI will come for at least a
couple years. I've seen potential funding for this stuff, but none
included easy to use gui on the list. By the time it comes there may
even be other options.
Even redoing the current user interface you'd probably want something
better than what we have today. Sortable tables, ajaxy forms with some
client side validation, that's something we'll need unless the UI
you're picturing is way 90s.
With freemarker we would end up writing that by hand, adding javascript
by hand (so in the end you'd end up having to learn javascript anyways),
then figuring out a i18n strategy, then solving again the
submit-back-submit problem with forms, writing our sortable tables, and
so on....
I just recently tried to make a very small site based on just restlet
and freemarker, and gave up because it was just too hard.
I tried that road because I thought it would have been simple, but found
out that in practice it was just a dream, in practice I had to struggle
in an IDE that provides no
support for that technology, and then struggle again to add javascript,
and so on... Templating a decent user interface is more than expanding
just a few variables here and there...
Looked around in the restlet forums, and found no one asking directions
to follow this kind of approach either. The approach might work fine
for simple sites written in a dynamic language where you can develop
live and it's ok to mix python _and_ javascript to get the
result you want, but so far I have the impression that does not work
very well in a pure java context.
Cheers
Andrea
!DSPAM:4005,482345e2249831628642973!
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
