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
