Hi,
looking at http://jira.codehaus.org/browse/GEOS-6176 I’ve realized there
is an annoying issue in general style editing: the current StylePage family
allows one to edit an existing style, already associated to layers, and
assign/change its workspace so that the layer won’t work anymore with it.
Imho, when submitting the code, the action should be treated in a similar way to
deletions, with a popup warning that the layers association will be changed, and that
the layers will be either have the style removed (if it’s a secondary style) or
reset to the default one (if it’s primary).
Similarly, the layer edit page allows to select a style regardless of its
workspace associations, for example, say “population” is now in “topp”
workspace, when editing sf:streams one still has the ability to choose
population and associate it to the layer. This should be forbidden, the
workspace specific styles from other workspaces should not be shown at all.
Finally, when changing the workspace for a store, all layers in it should be evaluated
and associations to workspace specific styles severed.
REST wise, I believe the changes above should be either be disallowed
or allowed to “cascade” like in the GUI
I recognise the danger, but what you describe would result in a terrible workflow for users. They would need to duck back through several screens to add the style back in, and they would need to depend on their memory to determine where the style was used.
It is too bad styles were not enabled / disabled in the Layer Configuration screen. We do a scan of the file for PropertyName references, and compare those against the FeatureType and disable the style for that layer.
Could we do the PropertyName sanity check when a style is saved, and raise warnings on the effected layers?
Hi,
looking at http://jira.codehaus.org/browse/GEOS-6176 I’ve realized there
is an annoying issue in general style editing: the current StylePage family
allows one to edit an existing style, already associated to layers, and
assign/change its workspace so that the layer won’t work anymore with it.
Imho, when submitting the code, the action should be treated in a similar way to
deletions, with a popup warning that the layers association will be changed, and that
the layers will be either have the style removed (if it’s a secondary style) or
reset to the default one (if it’s primary).
Similarly, the layer edit page allows to select a style regardless of its
workspace associations, for example, say “population” is now in “topp”
workspace, when editing sf:streams one still has the ability to choose
population and associate it to the layer. This should be forbidden, the
workspace specific styles from other workspaces should not be shown at all.
Finally, when changing the workspace for a store, all layers in it should be evaluated
and associations to workspace specific styles severed.
REST wise, I believe the changes above should be either be disallowed
or allowed to “cascade” like in the GUI
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don’t have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
On Sat, Nov 30, 2013 at 10:51 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
Hi,
looking at http://jira.codehaus.org/browse/GEOS-6176 I've realized there
is an annoying issue in general style editing: the current StylePage family
allows one to edit an existing style, already associated to layers, and
assign/change its workspace so that the layer won't work anymore with it.
Imho, when submitting the code, the action should be treated in a similar
way to
deletions, with a popup warning that the layers association will be
changed, and that
the layers will be either have the style removed (if it's a secondary
style) or
reset to the default one (if it's primary).
Similarly, the layer edit page allows to select a style regardless of its
workspace associations, for example, say "population" is now in "topp"
workspace, when editing sf:streams one still has the ability to choose
population and associate it to the layer. This should be forbidden, the
workspace specific styles from other workspaces should not be shown at
all.
Finally, when changing the workspace for a store, all layers in it should
be evaluated
and associations to workspace specific styles severed.
This all makes sense to me.
REST wise, I believe the changes above should be either be disallowed
or allowed to "cascade" like in the GUI
Well at the moment I don't think you can do a "move" type operation right?
Like the api requires to first remove the object and then re-create it in
the new location? This is done to be as "restful" as possible but I agree
this is indeed onerous.
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel