Chris Holmes ha scritto: > > > Andrea Aime wrote: >> Chris Holmes ha scritto: >>> But then again the only way to keep the comments if you're doing it >>> in java is to actually store the css file in the data dir, which >>> seems a bit nasty to me, to have two different persistence formats >>> for styles. Or else you again lose the comments >> >> Yep, that's the plan, have different storage formats for styles. >> > > Huh. Yeah, I browsed that thread. Sounds like adding a good bit of > complexity, to properly maintain multiple ones. I guess on the positive > side that could mean we could theoretically write parsers to read like > AXL files. But even that seems like it wouldn't work easily, since I > don't think AXL puts each style in its own file.
We also have this ongoing thread about storing multiple styles in a single SLD. Already two users (BC and Forward Slope) sounded in telling it's an important feature for them. > And how do we make the decision which storage format to put it in? Like > we flag what it's uploaded as? And then what, we provide tools to > convert the backend storage format, in case people want to change that? > They decide if they want to keep their comments in SLD or in CSS-like > language, and the other format gets them blown away? I guess the simplest idea is to just decide based on the extension of the stored file: .css, .sld, .axl You have a number of parsers from file to in memory GT2 Style objects, you scan them and ask if they can handle the file, if they can, the parse. No need for extra flags. >>> I imagine cascadenik probably loses comments. >> >> Imagine again :) If you want to use Mapnik you have to program in >> Python, it's not visual like GeoServer, is meant to be used as a >> library, they give you python bindigs, not a visual config >> enviroment. >> So you write the css by hand and point your python >> script to them. >> >> From the mapnik guide, the very first tutorial is: >> GettingStarted -- 'Hello,world!' using pure Python bindings. >> (http://trac.mapnik.org/) >> And from the very home page, "Getting started: 1) download the sources!" >> When that is your starting point writing a CSS file is a piece >> of cake. In fact, from a reference on the internet: >> "Michal Migurski has build a CSS-style equivalent which _compiles_ >> down to XML, hopefully making it much quicker and easier to get >> started with Mapnik customisation" >> http://simonwillison.net/2008/Aug/30/cascadenik/ >> > > Right, so it loses the comments, you have to compile down to the xml > every time. It's like saying that compiling java sources into binaries you loose the comments. The binary form does not have them anymore, but you still have the .java around, and your reference is the source, the binary is an accident of how java executes the code (if it was python we'd have no binary at all). > A similar 'compile down' would be when you're working with the CSS on > the javascript side and then persist it to GeoServer, it puts it in to > its XML (SLD) format. If a designer wants to maintain comments they can > keep a version of the file, and save it to GeoServer when they want to > make changes. Heck, we could even have a some part of the rest API let > people put and get CSS-styles, so they'd have a nice place to save it. > But when they want to apply it they save to GeoServer which stores it as > its native format. How do you go the way back? You have a style and you want to see what was the original format. Maybe two months later? While debugging styles this is important, if you're forced to debug the SLD version the CSS does not do you much good anyways. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
