Cascade delete Styles
---------------------
Key: GEOS-2947
URL: http://jira.codehaus.org/browse/GEOS-2947
Project: GeoServer
Issue Type: Sub-task
Reporter: Gabriel Roldán
Assignee: Gabriel Roldán
Fix For: 2.0-beta1
{code}
<aaime> I'd suggest to not cascade a deleation of a style, if a style is the
default of a layer, don't remove it, if a style is an "extra style", remove it
from the list
<aaime> also, polygon/point/line styles should not be allowed to be removed
<groldan> hummm
<aaime> we use them when building new layers
<aaime> or, raster too
<groldan> I don't think there's any cascading on styles
<groldan> like in they're first class citizens?
<aaime> yet they are used
<aaime> if this was a database you could say the fk cascade deletes
<aaime> I suggested above a way to handle style deletes
<aaime> what do you suggest instead and why
<groldan> reading over your comment...
<groldan> if you delete a layer, do not delete any style. If you try to delete
a style that's the default for a layer, do not allow it?
<groldan> take care and go change the layers style
<aaime> how?
<groldan> another option would be to delete the style and update the layer to
a default style
<aaime> revert it to the default for the default geometry? could work
<groldan> its going to be less annoying for the user I guess
<aaime> agreed
<groldan> say you actually WANT to delete the style, but have 10 layers using
it...
<groldan> ok
<aaime> yet we have to report which layers will be affected
<aaime> so I guess that's part of the helper as well?
<groldan> yes
<aaime> if the code is about to change 10 layers I want to know, as a user :-)
<groldan> there seems to be two kind of side effects: cascade delete and
config change
<aaime> and I also would like to know if the layer default style is changed,
or if only an altearnate one is removed, no?
<aaime> groldan, yes
<aaime> even removing a layer should, imho, just change the layer groups in
which the layer is included no?
<groldan> lets do that so, report back any change that's gonna happen before
the user applies the deletion
<aaime> for styles it's also relevant the kind of change is going to happen
imho
<aaime> default style or jsut one less alternate style?
<groldan> yup
<aaime> so I guess the helper will have to return appropriate beans listing
the affected parts?
<aaime> as in, it's not just a flat list of catalog objects, we need to know
what's deleted, what's changed for "data"
<aaime> and which layers are affected and how for styles
<groldan> not sure it has to return the actual beans
<aaime> separate methods to gather separate results?
<groldan> but an indication of what's going to happen, say a struct like type,
id, name, kind of affection
<aaime> that's a bean to me ;)=
<aaime> java does not have structs ;)
<groldan> yeah, I thought you meant the catalog objects
<groldan> like returning the affected LayerInfo etc
<aaime> nah, generic pojo
<groldan> yup, agreed
<aaime> and the pojo contains a list of LayerINfo and such
<aaime> no?
<groldan> not sure
<aaime> what would it contain otherwise?
<groldan> not sure :)
<aaime> let's make an example
<aaime> say I'm deleting a datastore
<aaime> the pojo, imho, could contain:
<aaime> 1) a list of layers that are going to be removed
<aaime> 2) a list of LayerGroup that are giong to be changed
<aaime> if I'm deleting a workspace, then the above, but also a list of
datastores that are going to be deleted
<groldan> the pojo in question is gonna be kind of recursive
<aaime> not sure we want that
<aaime> I mean, a flat list coudl be enough no?
<aaime> think also about presentation
<aaime> do you want to present a tree of what's going to be deleted?
<aaime> maybe a flat list is enough ;-)
<aaime> (a paged one)
<groldan> not a tree
<groldan> for presentation
<groldan> more like titles with lists
<groldan> The following layers are going to be removed:
<groldan> -
<groldan> -
<groldan> -
<aaime> indeed... so, why do you need the bean to be recursive?
<groldan> The following layer groups are going to be changed:
<groldan> -
<groldan> -
<groldan> to have a single bean able to hold any kind of affected list of
objects
<groldan> a single class I mean
<groldan> containing a list of the same bean class instances
<aaime> hmmm... maybe let's do it another way
<aaime> you propose a design in the jira
<aaime> and then I look into it?
<groldan> yeah stop wasting time here
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
