Soo... for now what I have done is added two methods to ResourcePool: Reader readStyle(StyleInfo); void writeStyle(StyleInfo,InputStream);
for reading and writing a style directly. When it comes to the point where we do support other types of styles, it will be low effort to change these methods to load a specific parser or factory, etc... But for now this at least gives us all the logic for loading/persisting of styles centralized to a single place. The downside is that styles are sort of a a special case. -Justin Gabriel Roldan wrote: > Andrea Aime wrote: >> Gabriel Roldan ha scritto: >>> 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? >> >> Yeah, I see the use case as a plausible one. Connecting >> it to the existing code is harder thought. The renderer, the svg >> generator, the kml generator all play with geotools Style objects >> directly. >> In order to make any use of different ways to specify styling we'd >> need some sort o generalization at that level. >> >> I guess we'd need to some kind of pluggable factory that given a feature >> and a generic style object (whose nature is unknown) returns >> the actual geometry that needs rendering, and some directions >> on how to render it (fill, symbols, labels). > On the other side, we could keep our internal object model for styling > being SLD and provide adaptations from anything else (css as you > mentioned) to SLD so not all the rest of the code needs to migrate to > something abstract and we can still keep the original style definition > in its native form, whatever it is... as long as our SLD implementation > with our custom extensions is powerful enough. > but you're right this may be too an abstract though without a > mandate/resources/strong use case to go for it. > > Gabriel >> >> This role is played, partly, by the SLDStyleFactory, but not >> for the geometries for example. We could generalize this further, >> introduce a style factory interface and an extension point, I guess >> we'd first need a solid use case (and resources) to do that first. >> So far the two examples we have at hand (SLD and CSS) seem to something >> that we should be able to coax into a single SLD object. >> >> 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
