-
Notifications
You must be signed in to change notification settings - Fork 94
TreeBrowserRefactoring
Primary goal: Decouple tree stuff from SonataAdmin
Secondary goals:
- Support multiple tree plugins, e.g. Dynatree: http://wwwendt.de/tech/dynatree/doc/samples.html
- Simplify configuration - remove dependency on FOSJsRouting
Currently the TreeInterface
classes contain about 70% model and 30% view (e.g.
methods for getting labels, serialization of nodes to arrays and icons) in addition
the individual forms also add view logic (create_in_overlay, edit_in_overlay, confirm_move).
This couples the tree view to a specific frontend implementation (namely, jsTree).
I propose that we split the model and view as follows:
/Tree/ModelInterface.php
/Tree/ViewInterface.php
/Tree/Model/DoctrinePhpcrOdm.php
/Tree/Model/DoctrinePhpcr.php
/Tree/Model/DoctrineOrm.php
/Tree/View/JsTree.php
/Tree/View/Dynatree.php
Where model and view are clearly separated and individually configurable:
cmf_tree:
class_mapping:
Foo/Bar:
icon: foobar.png
help: This is another option
valid_children:
- Bar/Foo
- Boo/Baz
view:
js_tree:
# these options could or could not be part of the interface
# and so made global. If so, this section would be used only
# for jsTree specific settings.
icons:
undefined: undefined.png
folder: folder.png
file: file.png
edit_in_overlay: false
create_in_overlay: true
confirm:
move: true
delete: true
The dependency on FOSJsRouting is, as far as I can tell, unnecessary.
It is currently used to generate the routes for editing the nodes and otherwise for things like passing the "children_url" to the tree javascript plugin.
Where a static URL is needed, we can simply generate the URL in twig.
In the case of dynamic URLs (i.e. the edit URL for each node) we can simply inject the Router object into the view and serialize the URL with the node data returned over AJAX.
{
'children': [
{
'title': 'Some node',
'path': '/foo/bar/node',
'icon': 'someicon.png',
'edit_url': '/app.php/edit.php?path=asdasd',
'view_url': '',
}
]
}
For this to work we will need to have some sort of registry mapping class types to routes, e.g.
cmf_core:
route_mapping:
Foo/Post:
edit: blog_post_edit_route
view: blog_post_view_route
Or something similar. The SonataAdminBundle bundle would automatically update these mappings, so no configuration would be required by the user.