Justin Deoliveira ha scritto: > Hi all, > > In working on the style editor in thew new UI I have once again run up > against the issue of how we handle styles in configuration. I wanted to > sum up my thoughts and get others peoples feedback about this. > > So first off, if you look at StyleInfo you will see: > > org.geotools.styling.Style getStyle(); > > The Style object corresponds to the UserStyle element in SLD. This is > the first oddity. We store the full StyledLayerDescriptor on disk but > only model a single UserStyle. > > Where i am finding this problematic is in the style editor. Where we > want to present the user will thefull SLD to edit. To do this we more > or less have to bypass the style that is actually on the StyleInfo and > load the underlying file from disk. > > And saving out is problematic as well. With all other configuration > objects we simply make the change on the configuration object and call > save, and that gets transparently persisted for us. But this is a > problem for styles for a couple of reasons: > > 1) just persisting what the StyleInfo.getStyle() represents loses > information. Basically everything outside of the first UserStyle element. > > 2) It would change the structure of the actual XML/SLD. For instance > anything that the style parser did not pick up and represent in memory > would be lost. Comments, etc... Currently we preserve that, and for good > reason. > > So the workaround has always been to have the UI read and write styles > directly from the data directory. With the old UI this was less of an > issue. Because when the style page was submited and applied, every > configuration object was reloaded, so the styles stayed in sync. Now the > user interface has to keep the StyleInfo.getStyle() in sync manually... > but said, there is no setStyle(Style) method. > > Also, what about other code that wants to update styles, like say, the > REST config stuff. It too has to know about these workarounds. > > This represents a problem with how we model styles imho. There are other > issues as well looking to the future. There has been talk of supporting > other types of styles that are non SLD, like support for cascadnik. Our > current model there would really be no way to handle this cleanly.
> I am curious to hear other peoples thoughts on this. And if other people > think that a retrofit of how we model styles is needed. I agree on the sentiment, however not sure how to provide a solution. Let me start with two lower handing fruits that I have some more definite ideas on. SLD storage wise, I too believe the file should only contain a Style element, and not an SLD one. A full SLD is meant to operate in the context of a WMS request, providing the definition of a map (in terms or layers and styles), or acting as a style library. Having people deal with anything other than just Style is indeed only source of confusion. So I would be very much +1 changing the parsing to deal with Style only (but keep on reading StyledLayerDescriptor for backwards compatibility) and change our demo material to just use a Style. CSS wise (a nice SOC topic btw, just added it to the page), I'd say we'd just have to parse the css definition in to a Style object, so API wise using a GT2 Style would not change. Yet, what would change is the way we parse, store, and present the style to the user. Adding pluggable parser is not that hard. The UI can be made pluggable as well. To support UI to disk and back I guess we'll need a style store extension point? For sure we cannot use the parsed version in neither case, as you have noticed, keeping the formatting and comments the user made in the source is very important. So, let's try to sum up a possible action plan: - add a style type field to StyleInfo - add methods in StyleInfo to get and set the raw style form (as i/o streams?) - have a storage facility that recognizes the type and knows what file to look for - have a pluggable parser that knows how to parse the contents coming from the storage into a GT2 Style object. Hmm... actually the storage could be really dumb, just know what the file name is and decouple the parser from disk (database?) access. Opinions? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
