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. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
