Am Dienstag, 22. August 2006 08:27 schrieb Philipp Bracher:
> > It looks like I'd still have to
> > extend the
> > command handling in my subclass of the AdminTreeMVCHandler. I
> > don't see a
> > practical way around the fact that getCommand returns
> > COMMAND_SHOW_TREE when
> > it can find anything else.
>
> No:
>
> if (StringUtils.isNotEmpty(super.getCommand())) {
> return super.getCommand();
> }
>
> This means if you pass a parameter command to the url this will
> return the command value. The property is set using the bean utils:
>
Ah hah! I did find that bit of code, and saw where PageMVCHandler called
setCommand(String) in int(), but didn't see any other use of the setCommand
method. I don't think any of the existing javascript code uses this command
parameter.
[snip]
>
> Conclution:
> - if you introduce a new own commands use ?command=mycommand in the
> url (tree, page, ...)
This is the part I was missing. I did find an example of this in the code for
restoring a version.
> - if you wanna change the behavior of one of the current trees
> methods, define the command in the config, which will overstrear the
> old behavior
> - keep in mind that a command itself can be a chain of commands which
> makes it very flexible
>
> > I am not sure but I think I need the subclass anyhow in order to
> > have a hook
> > for my Tree Configuration. At least that is the way it is done for
> > the other
> > Tree Handlers. Or is there something I am missing?
>
> I will fix it, so that you can define a configClass property on the
> tree definition node.
While you are at it what about a treeClass property on the tree definition
node, or allowing the configClass to determine what kind of Tree class is
used. Right now the Tree instance is created in the AdminTreeMVCHandler
constructor. So I needed a subclass of AdminTreeMVCHandler to override this
behavior anyhow. But then maybe this should be provided by the
TreeConfiguration class?
My AdminTreeConfiguration gets to configure the Tree in prepareTree, but
doesn't get to establish the tree. I needed to override getIcon(Content,
NodeData, String) in my Tree subclass to get the icon bit to work right with
my subclasses of the magnolia content types. Right now this icon selection
bit doesn't take into account that a node might be a JCR subtype of
mgnl:content or mgnl:contentNode.
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
