Extending ItemSelector and File Tree

Topics: Developer Forum
Nov 13, 2008 at 12:22 PM
Hi

I have a content item that currently uses an EditableLink attribute and therefore an ItemSelector to enable the user to select a second content item as a property. This works fine.

However, ideally I would like to restrict the selection of the content item property to a subtree of the site. Therefore I'm looking for a way to extent ItemSelector and/or the file tree page such that I can pass a new root node to the tree. I have looked at the existing FileSiteMapProvider and see how it adds the upload directories as root nodes and would like to find a way of injecting a new url rather than modifying the N2.Edit source as this would make N2 upgrades more complex. But so far I have been unable to find a way of doing this.

Does anyone have any ideas? Maybe I'm going about this in completely the wrong way so any help or suggestions would be appreciated.

To summarise I want to allow a user to select a content item from a subtree and not the full site.

Many thanks in advance, Nigel.
Nov 13, 2008 at 4:37 PM
Nigel, i think the easiest way to give user an ability to select items of a certain type would be to create a custom EditableDropDownAttribute implementation. Of course, extending ItemSelector to support a filtered view of item hierarchy would be nice to have. But let's think for a while, what would the end-user benefit from such a complex control. The problem of selecting an item could be tackled from two opposite sides: 1) taking everything and *constraining* it by a certain property (CLR "type") in a hope that a final subset will be sufficiently small to enable an effective selection; 2) on the other hand, we can directly *define* the query for what we'd like to provide for selection -- with the LINQ in hand miracles are possible!

Technically, to enable the second scenario, it makes sense to establish dedicated strongly-typed collection properties on container items, e.g.: for some hypothetical "OrderContainer>Order>OrderLine" hierarchy it should be some: 

public IEnumerable<Order> Orders { get { return this.GetChildren().OfType<Order>(); } }

Than, for the Order, in turn:

public IEnumerable<OrderLine> Lines { get { return this.GetChildren().OfType<OrderLine>(); } }

At the end, to query all OrderLines from all over the hierarchy of an OrderContainer established above, we'll need just:

public IEnumerable<OrderLine> AllLines { get { return
    from _order in this.Orders
    from _line in _order.Lines
    select _line; } }

The only case, where some sofisticated ItemSelector will be unavoidable is if you need to grab items of a certain type and you do not know the shape of your item hierarchy in advance. Anyway, building such ItemSelector would be a good excercise in programming :-)
Nov 13, 2008 at 4:54 PM
Hi esteewhy

Thanks for your reply. This was in fact the solution I implemented initially and it works well as the pages from which I need the user to select will all use the same type of content item. However, my colleagues and I do have a few usability concerns about this approach. These boil down to two issues:

1. There may potentially be a large number of pages from which to choose, making a drop down list probably not the best control to use, although I have considered using cascading drop down lists to solve this issue.

2. The hierarchy of pages is intended to be used as a means of categorising and subcategorising content, so for the user it will make sense to search for a particular content page by navigating the content in a tree view.

If it does end up being too much work to create a new tree view control then we may either go with the drop down list approach or provide some validation to force the user to make an appropriate choice. Many thanks for your help though, it is appreciated.

Nigel.
Nov 13, 2008 at 5:54 PM
By the way, i was just browsing N2 internals and found something very close to what we'd like to achieve. Inside EditManager.cs there is a GetEditorFilter(..) procedure which filters item hierarchy by "being page / non-page" according to admin user preference. All we need is to apply a different criteria, don't we ?
Nov 13, 2008 at 6:21 PM
Sorry to ask it here, just don't want to pollute this forum with a new topic. Doing a recent investigations got a too much of a conceptual question: is it feasible to implement N2 admin UI settings via web-parts personalization ? Looking at how simple is this feature to start with ([ http://msdn.microsoft.com/en-us/library/784d8z92.aspx ]) , i've immediately attempted to do something alike to a single property "Display data items". It turned out to be not so easy. Mostly because personalization deals within a web-part (=User Web Control) boundary. This means that a persisted state is private to a control, and there's not easy way to access it from outside and adopt this model for a centralized settings access. On the other hand, a personalization feature is something N2 is currently missing, so why not to start with admin settings ?
Coordinator
Nov 13, 2008 at 9:46 PM
Hi nigel, I committed a small change to allow selection of root node on the itemselector page (there's no integration with any editable). If you get the source you can use it like this:

/Edit/ItemSelection/Default.aspx?root=~/features&selected=~/features/register&tbid=controlOnOpeningPageID&defaultMode=Items&availableModes=Items

If you come up with a way to integrate it with the editable attribute I'd like to hear about it.
Nov 14, 2008 at 3:02 PM
Hi libardo

Thanks very much for the quick work. It worked a treat.

I've implemented a new Editable Attribute and a new ItemSelector that sets the url via a javascript function in the same way as UrlSelector and it works fine.

I'd also like to say that we've been using N2 now for only a few weeks and we are absolutely blown away by it. We have found it incredibly easy to extend and plug in our own Rhino commons and fluent NHibernate without having to change a single line of N2's code. Brilliant stuff; congratulations on a great piece of work.

Nigel.