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 ------------------------------------------------------------------------- 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
