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?
You are right here too. I will introduce the treeClass value instead
of delegate the creation to the config 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.
Should be more flexible in the trunk now, since introducin icons per
item type.
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
