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.
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 <dwinslow@anonymised.com> 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@anonymised.com Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Thu, Oct 20, 2011 at 3:13 PM, David Winslow <dwinslow@anonymised.com1…> wrote:
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.
I’ll be available to help on a Java version.
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
Can you open a jira about this issue?
Is there any quick way to check this besides making a sample page that uses ajax submits?
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Awesome. Tickets are at http://jira.codehaus.org/browse/GEOS-4815 (codemirror) and http://jira.codehaus.org/browse/GEOS-4814 (the general style editing work discussed in the current thread.)
The CSS module Maven build is already set up to look for Java sources in src/main/java/ and ready to do mixed-source builds, so we will be able to do the conversion one file at a time (probably want to use ‘mvn clean’ liberally though.) Mostly it will be pretty boring translations:
def func(a: String, b: Int): Boolean === Boolean func(String a, Int b)
I just made a commit (r16468) doing the translation for one of the smaller classes; hopefully it will be a useful example.
One of the more complicated bits will be the OpenLayersMapPanel which currently uses a multiline string literal as a template for OL setup code. We’ll probably want to move that out into a file, using Freemarker instead of java.util.Formatter.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Oct 24, 2011 at 3:51 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Thu, Oct 20, 2011 at 3:13 PM, David Winslow <dwinslow@anonymised.com> wrote:
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.
I’ll be available to help on a Java version.
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
Can you open a jira about this issue?
Is there any quick way to check this besides making a sample page that uses ajax submits?
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Just an update - most of the CSS module code on trunk is in Java now (I would like to make some changes to the underlying library before porting the last little bits.)
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Oct 24, 2011 at 10:00 AM, David Winslow <dwinslow@anonymised.com…1501…> wrote:
Awesome. Tickets are at http://jira.codehaus.org/browse/GEOS-4815 (codemirror) and http://jira.codehaus.org/browse/GEOS-4814 (the general style editing work discussed in the current thread.)
The CSS module Maven build is already set up to look for Java sources in src/main/java/ and ready to do mixed-source builds, so we will be able to do the conversion one file at a time (probably want to use ‘mvn clean’ liberally though.) Mostly it will be pretty boring translations:
def func(a: String, b: Int): Boolean === Boolean func(String a, Int b)
I just made a commit (r16468) doing the translation for one of the smaller classes; hopefully it will be a useful example.
One of the more complicated bits will be the OpenLayersMapPanel which currently uses a multiline string literal as a template for OL setup code. We’ll probably want to move that out into a file, using Freemarker instead of java.util.Formatter.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Oct 24, 2011 at 3:51 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Thu, Oct 20, 2011 at 3:13 PM, David Winslow <dwinslow@anonymised.com> wrote:
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.
I’ll be available to help on a Java version.
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
Can you open a jira about this issue?
Is there any quick way to check this besides making a sample page that uses ajax submits?
Cheers
Andrea
–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf