Rob Atkinson ha scritto: > Excellent analysis Andrea. I'd agree with all these points. > > Couple of points to explore; > > a) reusability of common components - things like file browsers etc > are often provided by the framework, but can we create additional > re-usable plugins easily - such as CRS choosers?
I think it's possible. Both wicket, gwt and pure javascript solutions like extj have the concept of a component. Struts2 has the concept of tag, which may be a table, a tree or the like, so I guess custom ones could be developed to have a file browser or a crs chooser. > b) in the case of plug-in components, this is achieved by > configuration round a standard interaction model, or by implementation > against a lighter-weight API. Most XML based approaches are in reality > attempting to create an interaction model with data-driven > configuration - but I agree that XSLT starts to get tto much logic and > its instrinisically hard to modularise and reuse. Data stores > providing separate UIs or data to drive a common UI is an interesting > case in point. IMHO, most (if not all!) the metadata required to drive > a feature type configuration should be drawn from existing registries > - CRS, feature type, user who logged in, datastore connection (tested > by a stand-alone reusable configuration). This means a high level of > sophistication between the UI and the sources of data, and creating > many one-off per-datastore UIs is not going to cut it unless we have > an explicit strategy to create a good library of reusable building > blocks, or a good data-driven template. I'm not sure I'm understanding 50% of what you're saying, but in my experience metadata driven UI (like the one we have now) tend to be very poor substitutes for hand crafted ones. In order to get close enough to a usable UI you have to specify so much metadata that you can probably do a custom programmed one with less effort and without having to know about a new XML soup required to provide the necessary information. > There is always a trade-off between ease of development of a single > implementation and ease of use. Development of good quality re-usable > peices can ease development and improve usability. This is an > investment, but is probably how we should approach the problem: for > each UI function, we should ask ourselves if we are getting the info > from the optimal place in the optimal way, and is it a common problem? Can you make me an example of "getting the info from the optimal place in the optimal way"? Afaik with the current configuration API we have just one place to grab each information we need to build up a UI, and this sounds like a very good thing (TM) imho. 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
