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. 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. 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. My 2c. -Justin Andrea Aime wrote: > Hi, > one year ago we tried to define a list of requirements and wishes > that a new UI framework should satisfy in order to be used for > the GeoServer UI remake. Analysys did not go so well, mainly because > at the time only one candidate (Wicket) was found satisfying all > requirement, and apparently there was not enough interest in redoing > the UI to invest on it. > > One year has passed and a few things have changed. Moreover, some > of us believe that the June sprint could be a nice occasion to > switch the UI to a new framework, meaning that we need a decision > on what we're going to use. > > Now, we can have a list of "requirements", but no framework will, > in general, satisfy them all. Also, not every developer will > feel the same about each item importance. > So what about coming up with a list of items, and then have > the developers that are really going to use the framework to do the UI > can do a vote? > > Here is my list of wishes, sorted in order of importance, on the web > framework that we'll be using: > 0) Open source > 1) active, big community, very likely to be still around in the next > 5 years > 2) supports internationalization > 3) allows the development of a modular UI, that is, an UI > where pages and components are located in the JARS, as opposed > to being stored in a single place, the web application itself. > This allows for new service UI to be plugged in, as well as > datastore specific UI pages, or service specific extensions > to the feature type configuration page (think of the current > page, but with WFS,WMS,WPS tabs for the configuration elements > that are relevant only to a specific service) > 4) good documentation, either has top notch web documentation or > a few up to date books on it > 5) fast development, meaning tool support in Eclipse, good > error reporting, fast development turnaround > 6) easy to learn for a java developer. The main user for it will > be a java developer that has to do some UI in order to expose > the configuration, he won't be an HTML/javascript/XML wizard > 7) compact, ideally would need just the definition of a template > and a backing class to control its contents and navigation > 8) possibly with a small payload in terms of jars to be > included in GeoServer (GeoServer is at the moment around > 30MB, let's try to avoid jumping to 50) > 9) possibly does not require JDK, but works with JRE instead > (so that we can distribute an installer with everything > included) > 10) (very personal) with as less XML as possible around ;) > > Wondering, what are other people's ones? > > One thing to notice is that requirement 3) is what kills most > of the web framework, in that it's impossible to attain, or > it's possible but makes development quite a bit harder. > Dropping it would open the gate to a wider list of > frameworks... what is other developer's opinion on it? > I cannot really think like dropping the requirement, since > I don't see how we could have a per datastore config page > or how could we allow the development of new custom services > outside of the geoserver code base. Yet I'm curious about > hearing other people opinions. > > 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:4007,47e7e0ce190951628642973! > -- 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
