Hi Andrea, I think you misinterpreted my comments :). I was not saying that we should not ship a UI in favor of a REST api, I was simply saying that with a good REST api, the UI becomes less of a necessity.
As for technology choice, you are putting words in my mouth :). I was not suggesting we commit to a UI based on a scripting language. Just that a decoupled UI would give us the ability to have a UI written in a "standard" java ui framework (like struts2), while at the same time allowing someone else to rip that out and replace with a different technology. Perhaps not useful enough to be a requirement. Let me phrase this requirement another way. "Having the ability to take the UI jars away and still have GeoServer run." I agree with you that forcing a UI built entirely in a scripting language is probably a bad idea. (Although I am not yet convinced we should rule out groovy/grails). However at some point you are going to need some client side scripting so you cant run from it altogether. Regardless, I would prefer we put off any discussion about technology choice until we actually do the technology evaluation. -Justin 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? > >> 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 > > !DSPAM:4007,47e8be72176153362379201! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
