Andrea Aime wrote:
Chris Holmes ha scritto:
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.
Yeah, that's one approach I considered as well... and ditched it out
because of frustration after a few days.
First issue was that I could not find any kind of support for mixed
freemarker/html scripting, you either get the first (in a lousy
way anyways) or the second.
Same goes for Jelly, no IDE support whatsoever.
Call me lame, but I've been programming with at least code
completion from the very beginning (VB6), I haven't wrote anything
without that kind of support for the last 10 years. Personally
I don't look forward to go back to a glorified notepad approach.
The second thing is that the frameworks provide you with components.
With just a template language, you end up re-doing everything from
scratch. Want a sortable, pageable table? Write your own.
Want a tree like ajax control? Same.
With wicket on the other side we'd have ready to use components,
the template would be pure html (which is very well supported
in any IDE I can think of), and we would not need to reinvent
the wheel, but just to use the ready made ones that the framework
provides. Of course, if you think of very simple pages, it
has overhead, I agree... but the moment we start adding
non trivial configuration, like complex type mapping or
community schema configuration, eh, I hardly see it done
without a Swing like support (that probably only component
based frameworks provide).
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.
So that's the product perspective. REST API of dual importance for the
easy to use, interaction designed javascript configuration through the
map and for batch configuration and the like. New Java UI important to
make developer's life easier, and to fix the worst sins of the current
UI from a user perspective. Ideally I'd like it pretty similar to the
ESRI admin server interfaces, so it's intuitive for people to switch
over. From a technology perspective I don't care that much, as long as
developers are happy.
Chris
Cheers
Andrea
!DSPAM:4005,4823376a214773668746562!
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
