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.