How complex can this be?
How long would it take you to implement the functionality to the left?
I have already spent over a day implementing a tri state tree. The scary part is that I have not even tried to build the tree myself, it was a completely innocent chain of events that led to this stage.
Let me explain a bit about what I am trying to do first. It is a tree that shows the assoication of an entity to a hierarchy. To make a concrete example, let us say that we have an employee entity that should have responsability on a part of the hierarchy. The hierarchy is 5 levels deep, and fairly big.
At first, I tried to simply use the ASP.Net Tree View. That didn't work very well. Too much data was sent to the client. So I needed to do lazy load of the tree, using Ajax. The ASP.Net tree view supports that, but, to my utter lack of amazement, not in a way that allows me to plug in easily and handle additional concerns after the load has happened.
Time to write my own tree :-(, that isn't very hard, actually, there are numerous examples of tree around, and it was fairly easy to turn MkTree into an ajaxian one. Now I had the proper extension points, and I could turn my mind to the other concerns. As you can see in the picture, there is a checkbox that indicate whatever the user is associated with this node or not. So far, not so hard, I can handle that with ease.
The problem is that I need to handle the third state, where the assoication is in a deeper level, and still show it to the user. So, in a 5 level hierarchy, where the user can be associated to any of the levels (many to many, btw), I need to find out if it is associated with this node or any of its children.
17 left outer joins later (and no, this isn't just a number, I really got to that), I realized that I have no idea what I am doing and that I probably want to stop before I reach the triple digit joins statement (don't ask, but it was a hand written query, to stem the OR/M sucks complaints) again.
Solved that (with MutliQuery and by thinking about it from the other end), and found out that the hierarchy is so nicely real world, so you can have a 4th level node that doesn't have a 3rd level node, which should still go under its grandfather on the 2nd level. And if that is not enough the next issue in line is solving the issue of editing a partially loaded tree, what do I do with the unloaded state? Yuck!
Right now, it is compromised of:
- User Control
- Two custom server controls
- Web Service
- JavaScript on the client side
- Controller
- Create querying with NHibernate
- Complex UI interactions
It is a %$#@$& tri state tree view, for crying out load, and I can't believe how complex this has turned out to be. And it is not over yet.
Comments
I recently had this exact same problem. The client needed a whole lot of information shown at the same time for some reason only the devil knows, and at the time I thought the tree view was the best way to describe the data.
We arrived at a similar solution to yours, only without ajax. We load everything up front and show it. It ends up being a huge page, heavy as hell, slow as molasses, but the client wanted a lot of information available and they have it. They are happy and that's what's important in the end.
But that's besides the point. I still believe that this problem can be described using a different metaphor, not necessarily a tree view. I would choose to rethink this as a multi-step interface, kind of like a wizard maybe. The tree view is a very nasty structure when there is a lot of information to be shown AND gathered.
You can show the related entities for a given parent entity and have a workflow to add new relationships through a search or browse scheme. And to be frank, I thought the tree view would be the fastest solution, the easiest to describe what I needed to show, but it turned out to be hell. And the time I spent trying to get it to work was time I didn't spend rethinking the problem to apply a more graceful solution. I fell short on the solution, that's sad but true.
Anyway, I'm not really providing a solution, just moral support. I hope this applies to your problem, because it might very well not apply.
Rezlaj,
The problem is not just with showing the data, the user also need to select stuff from the tree.
That's what I'm saying, I think the problem is exactly with how you show the data for update. Navigating a tree view is one thing, getting a complete snapshot of the whole hierarchy by looking at the root nodes is a different story, which I'm not sure falls within the scope of the tree view paradigm.
In my experience a tree view is OK for showing information and navigating it, not so much for retrieving it from the user, especially when you are nesting 5 levels.
I'm thinking something like what cd burner software does with the file system. I remember there were some that showed the complete file system tree view and you had to browse and check the items you wanted to burn. Needless to say, this was very messy if you had to copy files from far away in between your folders and drives.
Now that paradigm has moved towards the Add-To-List scheme. You still have the tree view, but just for getting to the item you want to add, then you take action to add it by clicking on the Add button.
I think it might be a more complex procedure, but it's broken down to smaller steps, easier to manage with simpler logic and it refers to an already known paradigm so the user doesn't have to learn a new way of working.
Does this make sense in your problem?
I am not sure, different levels on the tree have very different meanings, and the idea is that you can give an employee permission on a level 3 which is different than giving them permission on lever 4 item that is a child of the level 3.
Part of the problem here seems that you are intent on reproducing the Windows user interface way of selecting from a hierarchy rather than write an interface better suited for the web.
Without more information it's difficult to know what to suggest.
[)amien
Check out the extjs tree control (http://extjs.com/). Very extensible, and easy to submit data back to the server using JSON.
Eric,
Thanks, but I don't actually have an issue with the UI itself, it is the data that is driving me crazy.
That's the exact same scenario I had, but it wasn't in security. Parents are not only grouping elements, but actual entities in themselves.
After some soul searching I think I found what was bothering me about this situation. A tree view is misleading in that it tricks you into believing that the parent and children are somehow strongly related, when they are not. When all you have to do is view the data then it's a nice structure to use, but when it comes to editing the paradigm falls short.
Then I think a valid question would be, what is an element in that structure exactly? For example:
|__+ child1
| |__+ child11
|__+ child2
What is the relationship of child1 to child11? only a parent/child relationship, that's it, no inheritance of behavior of any kind.
In that case I'd say that the child11 element stands on its own, not as child of child1. That is to say, child11 is root\child1\child11, not the element child11 of parent child1. I'm not sure I'm getting my point across.
So, how would you show the information for the user to choose in this case? How about a list?
root
root\child1
root\child1\child11
root\child2
Each node is equally important in that case, there are no behavioral groupings, and you can choose root\child1 without misleading the user to think that root\child1\child11 was chosen as well.
And the hierarchy is somewhat present in the ordering you give the list.
I think this would have been a much better solution in my case. It would have been hard to get the client to agree because they wanted a tree view, but that's another story.
Is it too cumbersome to do it in this way?
My current case is a hierarchy, and a big one, so I can't flatten the data.
There is a relation between the nodes, if I give you a permission on Root1, you get permissions on Root1\Child1, but there is also a distinction if you get a permission on Root1\Child1 directly. And it is valid to have both.
I was trying hopelessly to set up some whacky file permissions in windows 2003 server once, and your scenario reminds me of that a little. Despite me not being a windows security guru, there seem to be so many factors that make setting up permissions a head-scratching affair.
For example, you have a file, then you can pick groups and users who and chose if certain permissions are allowed or denied. On top of that you have inherited permissions from parent objects, and you can set up custom permissions that override the standard types. To top it off some permissions include other ones, and contradict otherones, and some are mutually exclusive. Jeesh!
Anyway, the bottom line is that no vanilla GUI component is gonna make this manageable. MS decided to let users actually test to see what the effective permissions are for a given object. This suggests that the permissions assignment GUI itself doesn't cover all bases, so additional tools are needed.
Is your scenario as complex as this? Could it be that the tree control isn't gonna cut it? Could be worth a look for inspiration? Did all that make any sense!?
I've been suffering from that for quite a while now, but I haven't had the chance to write my own...
perhaps is time to create an open source treeview!
sounds like a project for Super Ayende
@Ayende,
"I can't believe how complex this has turned out to be."
Just because you can describe a solution in one sentence does not necessarily make it easy!!!
As Rezlaj points out, quite often trees really suck even when working with hierarchies. They're a real nuisance to implement and quite often are less usable than other alternatives. I might also add that I don't recall ever seeing a custom tree implementation with fewer than 1000 lines of code... particularly if it is editable. Ahh well.
Best of luck wrangling that Tree, mate!
The problem is not the tree view implementation.
The problem is the data for it and the interaction with the server.
Comment preview