Luca Morandini wrote: > Pure Java... wow ! Do you plan to write your mark-up using servlets ? ;) > I think you have hit the nail on the head; ie why we have been looking at use interface frameworks so carefully.
There is a list of requirements Andrea was shopping for on a wiki page somewhere, the two I am following most closely are: - a ui framework where the AJAX goodness is handled by someone else, both Wicket and GWT have the concept of widgets - a ui framework that will allow us to be modular in some fashion; it does not have to be pretty The modular one seems a little hard to explain. Andrea got the part about "dropping in or removing a jar" to control which GeoServer capabilities are available. Here is what I mean about non pretty: - we could have a naming convention for passing control between each modules "action handler" or whatever the framework calls it - we could make each "module" a seperate WAR and ship GeoServer as an EAR - this would allow say a small GWT user interface in each WAR etc... let each WAR register itself in a JNDI directory for the main user interface screen to "discover"... As for AJAX goodness; perhaps that is just me: - trying to be fashionable; AJAX does result in an improved user experience - trying to be lazy; there is no way I want to track what each browser is capable of in a world where Microsoft has a IE 5 standards mode being advertised by Safari 7.1 (or whatever) Here are some examples of wicket AJAX goodness (make sure to check out the tree example with the debug window open...) - http://www.wicket-library.com/wicket-examples/ajax/ Basically I want GWT or Wicket (or someone other than me) to keep up with the browsers. GWT is really fun and has an open layers widget already made as a codehaus project; it has some limitations (it is a compile step where you compile Java into JavaScript, and as such the compiler wants to see your *entire* program). Wicket has a very clear design; the "webdesigner" defines an html page with slots for the "widgets", and the Java programmer wires up the widgets. > Therefore, the GeoServer packaging options may look like this: > 1) Development (all-but-the-kitchen-sink). > 2) Appliance (just the core functionality, without fancy stuff or the UI). > 3) A-la-carte: pick your own modules (possibly using Maven) with or > without the UI. > Yeah you got it, Jody ------------------------------------------------------------------------- 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
