Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

should we cascade deletion of routes / menu entries when content is deleted? #98

Open
dbu opened this issue Jan 22, 2014 · 6 comments
Open

Comments

@dbu
Copy link
Member

dbu commented Jan 22, 2014

the dangerous part about that cascading is that deleting that route will also delete all children routes, which could be a really bad idea. (unless your content tree and route tree have the same structure, which would mean that by deleting the content, you delete its children anyways which would be associated with the routes you delete because they are children of the route. confused yet?)

@ElectricMaxxx
Copy link
Member

I think it is important to clean things up after deleting. And i would wish a route/menu to be deleted, when a content was deleted.
I know of the Problems of cascading. But normally i would create an equal (sub-) structure for my routes as i have the for my content. I i delete a content item with many children, i know that all children a gone too. So i want all child routes to be deleted too.
But as i know, that equal route tree and content tree structures are not the usual case i would apologize to put these stuff into the AutoRoutingBundle. This bundle takes care on creation of routes by configurations. So it can take care of deleting them.
@dantleech is asking for some annotation support for the routing, this would be an good point to put those behavior/setting, too.

@lsmith77
Copy link
Member

lsmith77 commented Mar 2, 2014

i don't think we should cascade. i fear this maybe need a checkbox or something to manually trigger the cascade.

@dbu
Copy link
Member Author

dbu commented Mar 7, 2014

if there is a way to add behaviour to the delete confirmation dialog, we could make the admin extension for routes add such a checkbox to the delete confirmation. and if its checked, continue with deletion.

@rande can an extension somehow change the delete confirmation dialog (or the button area at the bottom for save / delete) and add a checkbox?

@rande
Copy link

rande commented Mar 7, 2014

@dbu The extension is not that magic ;) You can probably use an extension to update the default controller. But this will be not ideal.

@dbu
Copy link
Member Author

dbu commented Mar 7, 2014

thanks thomas. then i guess we can either provide a controller that people can manually use or that the extension automatically puts there if the admin did not specify a non-default controller. the later sounds a bit funny but doable. as soon as somebody is doing their own controller, they would have to take the route deletion part into their own hands.

but what about an extension aware controller? sounds like a stupid idea or doable? maybe with a ControllerExtensionInterface? i also see need to update other parts outside the form itself, for example for symfony-cmf/core-bundle#121

@rande
Copy link

rande commented Mar 7, 2014

a solution might be to use some events in tje controller or in the admin.

But adding too much events might kill performance.

Thomas Rabaix
http://rabaix.net - http://sonata-project.org
On Mar 7, 2014 5:42 PM, "David Buchmann" [email protected] wrote:

thanks thomas. then i guess we can either provide a controller that people
can manually use or that the extension automatically puts there if the
admin did not specify a non-default controller. the later sounds a bit
funny but doable. as soon as somebody is doing their own controller, they
would have to take the route deletion part into their own hands.

but what about an extension aware controller? sounds like a stupid idea or
doable? maybe with a ControllerExtensionInterface? i also see need to
update other parts outside the form itself, for example for
symfony-cmf/core-bundle#121symfony-cmf/core-bundle#121


Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-37041924
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants