I spent a fair amount of time last week exploring the ins
and outs of the new Tree in 4.5. First and foremost, I love the
additions. For example, adding a custom picker data type is super easy
now - just inherit BaseTreePicker!
But I also founds some roadblocks and other quirks that I'd like to
see improved. Here are my suggestions:
If a TreeType is passed to
TreeControl, only display that tree.
Currently, whether you pass
a TreeType or App (or both) to the new TreeControl *all* trees for the
relative application are shown. For example, if I want a CSS picker that
allows me to assign a stylesheet to a page, I would pass "stylesheets"
as the tree alias. However, the entire Settings tree would be displayed
in the picker, including Templates, Scripts etc.
Allow a custom
Tree to be used with TreeControl without it being in the database, nor
associated with an Application.
Currently, a custom Tree (that
inherits from BaseTree) is picked up at application start, but then
fails to be registered because it doesn't have a matching record in the
database. It can then never be used with TreeControl.
I suggest
these Trees not be filtered out, but registered with a null App object.
Permissions wise, they should be considered a free-for-all (without an
App object, there's nothing to check against).
For me, the most
obvious scenario is building a custom IDataType with an IDataEditor that
inherits from BaseTreePicker. It would be awesome to build a matching
ITree in the same assembly to be used with the picker, and know it can be used without any database requirements.
Allow a custom id to be recursively passed to the TreeDataService.
Similar to the scenarios above, imagine there is an IDataType with prevalues, and those values are required to render a tree (launched by a BaseTreePicker, IDataEditor). It would be great to be able to pass the DataTypeId so that the prevalues could be fetched and recursively used to build out the tree.
Currently any extra values are inaccessible via TreeRequestParams.
Suggestion: App Independent Trees
I spent a fair amount of time last week exploring the ins and outs of the new Tree in 4.5. First and foremost, I love the additions. For example, adding a custom picker data type is super easy now - just inherit BaseTreePicker!
But I also founds some roadblocks and other quirks that I'd like to see improved. Here are my suggestions:
If a TreeType is passed to TreeControl, only display that tree.
Currently, whether you pass a TreeType or App (or both) to the new TreeControl *all* trees for the relative application are shown. For example, if I want a CSS picker that allows me to assign a stylesheet to a page, I would pass "stylesheets" as the tree alias. However, the entire Settings tree would be displayed in the picker, including Templates, Scripts etc.
Allow a custom Tree to be used with TreeControl without it being in the database, nor associated with an Application.
Currently, a custom Tree (that inherits from BaseTree) is picked up at application start, but then fails to be registered because it doesn't have a matching record in the database. It can then never be used with TreeControl.
I suggest these Trees not be filtered out, but registered with a null App object. Permissions wise, they should be considered a free-for-all (without an App object, there's nothing to check against).
For me, the most obvious scenario is building a custom IDataType with an IDataEditor that inherits from BaseTreePicker. It would be awesome to build a matching ITree in the same assembly to be used with the picker, and know it can be used without any database requirements.
Another tree suggestion:
Allow a custom id to be recursively passed to the TreeDataService.
Similar to the scenarios above, imagine there is an IDataType with prevalues, and those values are required to render a tree (launched by a BaseTreePicker, IDataEditor). It would be great to be able to pass the DataTypeId so that the prevalues could be fetched and recursively used to build out the tree.
Currently any extra values are inaccessible via TreeRequestParams.
is working on a reply...