Hi, I just went quickly over the topic so I guess I understand the problem but may not be that insightful about a proposal for a solution. Yet, let me just chip in before I forget.
I guess you said we may want to leverage other sorts of styles definitions than ogc's ones, which seems clever to me. To do that my first reaction would be to use some way the IAdaptable pattern in StyleInfo. Something on the lines of StyleInfo.canAdapt(Class styleClass) and StyleInfo.getStyle(Class<T> styleClass):T Implementation wise we can allow the factory that creates a styleinfo receive a String and held it internally. It may well be the SLD contents or any other thing and we can store it in the database verbatim if needed or as a file. So no matter if we store an SLD or a single SE style or some other sort of style definition, it could evolve to support other formats easily? ok, it may be an off topic or simple stupid idea but wanted to tell what my though was when reading through the topic. Gabriel Andrea Aime wrote: > 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 > > > > ------------------------------------------------------------------------------ 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
