Justin Deoliveira ha scritto: > Gabriel Roldan wrote: >> 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 >> > Interesting thought Gabriel. I agree that this would be a good > application of IAdaptable. I know there has been push back to this > "eclipsism" because of the complexity but I think this circumstance it > does indeed make sense. > > With a bit of variation I think it would also solve another issue. One > of the problems we have with how we store stuff is afaik we only just > read the first style in an SLD. Which means if someone is using an SLD > as a "library", they are kind of stuck. One thing that would be cool > would be: > > FeatureTypeInfo ftinfo = ...; > StyleInfo style = ...; > > //load the style for the feature type > Style se = style.adapt( Style.class, ftinfo ); > > Basically parameterizing Iadapable so that in this case only styles > which will apply to the feature type would be loaded.
A few random notes: - do we really want/need to support style libraries? I thought the idea was to simplify style documents so that they contained only one Style root element. Most non trivial styles are very long, not sure I see the advantage of putting togheter many of them in a single file, it would also make the user chioce less direct. You associated a feature type to a style library, you get back the first style that applies? What if there are various of them and you did not realize it? How do you debug that as a user? - I like the idea of storing just a string representation, whatever it is. I'm not sure I understand the need to IAdapt it thought. What choices do we have today? We want the style as a String, or the style as a GeoTools Style. IAdaptable fits when the conversions set is open ended, I'm failing to see the other potential cases. - Parsing the style takes time, so for sure we don't want do perform the parsing for each WMS request, meaning we also need to create a cache of parsed styles somewhere, the cache should also be smart enough to avoid doing string equalities to check if the style was updated, but rely on getters/setters of StyleInfo instead. So I guess it would be better implemented inside the StyleInfo itself. 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
