When we did the WMS 1.3 work we did some work toward factoring out "style
format" into something more extendible. The immediate use case was to
support SE 1.1, but when reworking the classes I had CSS in mind as well. If
you look at org.geoserver.catalog.Styles class you will see the idea of a
handler which isolates the parsing of a style.
I could see an additional CSS handler... perhaps contributed via extension.
It would then be a matter of retrofitting the STyleINfo interface to have
some notion of "format" or "type"... and link that up to the appropriate
handler.
$0.02
On Thu, Oct 20, 2011 at 7:13 AM, David Winslow <[email protected]> wrote:
> Hey all,
>
> In the comments on http://jira.codehaus.org/browse/GEOS-4767 Andrea noted
> that perhaps it makes sense to start working toward unifying the style
> editing user interface between the core SLD editor and the custom editor I
> use for CSS. When I started work on the CSS page it was important to me to
> include an OpenLayers map that would update in real-time, to make it easier
> for folks to see how a quick tweak to a CSS style can affect the look of a
> map. But as Andrea points out there's no reason that this sort of thing
> can't work with SLDs or even other styling languages that we support in the
> future.
>
> GEOS-4767 is just about a couple of small tweaks to the UI - changing the
> wording of some labels, adding a little new functionality. But while I had
> the hood up I decided to make some deeper changes, implementing a couple of
> ideas I've been thinking about for some time. I've attached a few
> screenshots to the ticket (again:
> http://jira.codehaus.org/browse/GEOS-4767) of the UI I settled on (for
> now.) I'll commit it to trunk shortly, so others can try it out too.
>
> I think it would be nice to have these features go into GeoServer core and
> extended to support both CSS and SLD. However, at the pace I've been able
> to work on the GeoServer UI I don't think it will happen any time soon.
> Here is a list of blockers I see in the way:
>
> - GeoServer does not currently know what format styles are in (in fact
> the CSS extension keeps both SLD and CSS around - GeoServer renders from
> the
> SLD, but the user sees the CSS when she goes to edit.)
> - The UI module is not generic, neither its persistence mechanism nor
> the editor component that is used. So we'd need to give it the "extension
> point" treatment to make it able to edit SLD as well as CSS.
> - The CSS module UI is nowhere near ready for promotion to extension
> status, let alone inclusion in the core.
> - The test coverage is close to zero (the CSS converter itself has
> nearly 90% test coverage, but I have sadly never gotten around to
> learning
> how to use the Wicket tester.)
> - There are hard-coded (and thus untranslatable) strings littered
> throughout the code - some in templates, some in the source code.
> - Since it is written in Scala, the code relies on the fairly hefty
> Scala standard library; apart from not being familiar to other GeoServer
> developers this introduces an ~8MB of extra footprint.
>
> I don't expect folks to suddenly start learning Scala, so I will work on
> porting the Wicket code to Java[1].
>
> But I would like to get a bit of conversation started about adding format
> information to styles in the catalog and the API for the style format
> extension point. While I'm at it I'll point out that there is room for
> another pair of hands or two in this task: it would be quite possible to
> start on i18n for the templates, and doable (albeit more complicated) to
> work on test coverage before the Scala port is finished. Additionally, if
> anyone's interested in helping out with the porting work I'm happy to
> explain Scala syntax, etc.
>
> Side note: It's currently not possible to use the CodeMirror component with
> a Wicket AJAX form submission; that would be useful as the live updating map
> is a lot less slick if we have to reload the page every time we save :)
>
> Thanks for reading.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> [1]: The css conversion library itself makes heavy use of several Scala
> features so I don't see the CSS extension itself moving away from Scala.
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
