Hi Andrea,
Feel free to start opening tickets if you want to, I just haven't gotten to
it yet.
>
> - The CSS editor on submit converted the style to SLD, thus generating
> visible user errors/feedback about the process. The current editor instead
> does not that, and the preview occasionally is just a broken image, forcing
> the editor to go hunt in the GeoServer logs for the actual error. I warmly
> recommend to get the previous behavior back, it can be easily done without
> any knowledge of the actual style type by calling "parse" on the
> StyleHandler. This would also improve SLD own editing, as sometimes one
> uses a filter function that does not exist, and formally, the style still
> validates fine. I'd add this behavior at last to "apply", I'm not sure
> about "submit", since in the past the editor allowed to save invalid
> styles, it may be that someone wants to just save a invalid work in
> progress for whatever reason (e.g., meeting, lunch break, general need to
> get away from the computer)
>
> We still parse the style to SLD and display errors when clicking
"Validate" (at least from what I have seen). Should be easy enough to also
add this functionality to apply. I feel like we should retaining the
ability to save invalid styles in order to save large WIP styles and not
risk losing work.
>
> - When hitting "apply" the entire page is reloaded and so is the
> preview... this is highly disruptive when editing a multi-scale style, as
> the preview is reset back to showing the entire layer. The CSS editor
> submit button applies "in place" instead, keeping the map where it is, just
> showing the new style (without requiring the editor to interact with it,
> e.g., no moving or zooming required)
>
> Good to know about losing zoom levels when clicking apply. I have been
having some dificulties getting wicket to play well with the various
submits used on the style, so I expect that is why we are getting a reload
where one should not be necessary.
>
> - As noted before, the screen space is not used in an optimal way,
> often forcing to scroll up and down while editing and previewing
>
> I agree screen space usage is suboptimal, although this is more of a
problem with the geoserver UI in general. It is definately more obvious
with this style page, as you are both editing and viewing things on the
same page. I am open to suggestions that conform to the curent GeoServer UI
conventions (limited width, etc.).
Torben
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
