Walaa wrote:
You didn't answer my questions.?
You are right. Sorry.
Walaa wrote:
How would you bind some classes linked to each other with properties (just like entities and their related entities) t the ASPxTreeList?
You would use a projection into a dumb object that had a synthetic parent node id and child node id. Maybe this would be done in Linq or more likely in a unioned view in the database.
Walaa wrote:
Do you load everything in one go, or you load the children of a node when it gets expanded or clicked for the first time?
Usually the tree control allows you select this behaviour.
Walaa wrote:
Does the ASPxTreeList perhaps give you the ability to define a datasource per level?
No, but that is interesting. Do you know a treelist control that does that? It might be worthhile investigating it.
Walaa wrote:
Anyway, my 2 cents are:
In ASP.NET, I don't recommend loading the Tree at one shot with all the data in the database.
You don't need to fetch entities for a read-only view, Trees are read-only right?
Not always read-only if you are dragging nodes around. But in this case I am not so the tree is indeed read only
Although the tree is read-only, every time the user selects a node, a row needs to be inserted in a table with the current user id and the node's identifier. Pretty simple stuff really, but I don't see what LLB object to use. I would feel pretty silly creating a projection into a home made type to do this if actually an LLB entity collection created the appropriate way could be used.
If an LLB entity collection can be used, it could carry with it as prefetch paths the other tables that record the user's previous selection making it easy to find out if the checkboxfor the node is checked or not. Otherwise I need to handle a row preparation event to find that information. Not only that, when the selection changes, the prefetch could easily be found and a row added or deleted.
I gave this task to a developer who produced a solution that would have just as easily been done with an asp control and an SqlDataAccessAdapter. Lots of code was working everything out. I was hoping these higher functionality tools could do this simple task with just a few lines of code. If not, why bother with them in the first place?
The reason for getting detailed on this is that the upcoming work has dozens of examples where this selection behaviour is needed. I would like to establish the most efficient way to use the tools to get robust results with the minimum of code. If it were just this one time, I would probably go with whatever worked.
I'll carry on experimenting, but I feel sure there is an elegant way to do this hiding somewhere.