Andrea Aime wrote: > 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? Well I did not mean the example to be 100% correct, but change to a list of array and the point holds. I don't know if we want to support SLD libraries per se. But the use case does not seem to extreme to me. I am sure if we look hard enough we can find someone that uses a single SLD document for all there feature type styles.
> - 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. Well I think it comes in to get back the information you want. Do you want the full SLD, or do you want just a single feature type style, or maybe you want the raw string as it sits on disk, all could fit into the context of iadaptable. That said, I did think about this, just storing the raw style as a string. It has the benefit of keeping around the raw structure around. Seemed a bit clumsy though... > - 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. Yeah... we definitely want to cache, which is why i like ResourcePool as the home for this stuff. While I think iadaptable *could* work in this context I am still hesitant to use StyleInfo for things other then just a dumb java bean. > > Cheers > Andrea > > > -- 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
