Andrea Aime wrote: > 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 was thinking, instead of sld library mode, that we wanted to support other sort of styles than SLD ones. And if you ask me I reckon I don't know yet what those are gonna be, so this may well be overarchitecting and I just got wrong the intention of supporting other kinds of style definitions? > >>> - 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 >
------------------------------------------------------------------------------ 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
