Justin Deoliveira ha scritto: > 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.
Sure, but that sounds like theory, and I reason in practical terms instead. So I guess I can rephrase the question as, how do we make sure this does not become confusing for the user? Do we log somewhere which style has been actually picked up out of the library? (possibly, in the UI)? Do we have a plan to offset the cost of parsing tens or hundreds of styles when we're actually just looking for one? (once we go down that path we relinquish control on how many styles the sld document contains). >> - 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... If we want to avoid loosing comments and so on, I guess there is no other way. Somewhere the raw form must be available. Keeping it in memory is a possible way, otherwise we need some kind of direct reference to the file on disk (or the record in the database... but we can decide that is a implementation detail of StyleImpl, and that a Hibernate based implementation will keep something other than a path to allow the raw form lookup). 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
