I have about 200 categories that are nested. I am currently reading the documention on the C5 generics library. I am not sure if the C5 library is overkill or not. I am looking at converting all my custom algorithms to the C5 implemention.
This is what I need. If a certain category is chosen i need to find its parents, siblings, direct children, and all children.
This is the way I have it set up. To find the:
Parents:
I start from the current location then loop through the list and find the current parent. When I find the parent I loop through the whole list again to find the next parent and so on.
Siblings:
I loop through the whole list and find all the nodes that have the same parent as the choosen node.
direct children:
I loop through the whole list and find all nodes that is a parent of the choosen node.
All Children:
This one took me a while to figure out. But I used recursion to find all children of the choosen node.
Is there a better way to implement something like this?
Why does it have to be collection-based? I would just create class Category with properties Category Parent and IList<Category> Children. That way, finding parent or predecessors is really easy (and fast!), finding children too, siblings are children of parent except the current category, so they are easy too. And finding descendants is trivial recursion.
Related
When handling the DataGrid, in code-behind I can walk downwards the visual tree, to cells and their descendants.
In XAML, FindAncestor lets us walk up the visual tree to access a target element that has no Name.
As there is no FindDescendant, I wanted to figure out how to walk downwards, not in code-behind or by MVVM.
No, at least at the moment, such FindDescendant feature is not here. And the main problem you may face trying to implement it by XAML-only is the fact there could be zero or more results matching your criteria, unlike walking the tree up where you see only one parent (or no parent at all for the root element). So the result is a collection, not a single element.
Another aspect of the problem is an ability to alter children representation by template selectors: that way, a parent node should be aware of all alterations down the tree, all the way down (maybe, zillions of levels). However, from system design point, it's better to hide such knowledge and delegate it to children nodes themselves.
Not last and not least: if you alter a parent depending on a child behavior, it may cause a circular dependency/lock if in turn the child is instructed to track the parent behavior via FindAncestor. XAML deadlocks? Thank you but no, thank you!
So, all after all, it could be very arguable ability.
I want to show the expand option against a tree node even if the node has no children. Is this possible?
(The expand option being the little plus sign in a box to the left of the node.)
If your purpose is to dynamically load children nodes when expanding the best solution is to add a fake child nodes to all the leaf nodes. Then replace the fake node with real ones when needed.
Try it with property TreeNode.PopulateOnDemand = true; - this is ideal for dynamically created trees and it adds plus sign icon also to node with no children.
Sorry this is not a direct answer to your question, but I do feel it is relevant.
Why would you want to do this? It is confusing for the user.
(I have just been through exactly the same process in another environment and user feedback was "This item is broken and won't let me see what's underneath like the other ones do").
In short, I would recommend evaluating the requirement carefully before you proceed.
I want to create an expandable empty treenode in C#, i.e. a treenode which is empty and has the [+] sign beside it. The reason is because initially it is empty, but once a node is clicked, I want to populate it with many child nodes.
The only problem I am facing is that empty treenodes aren't expandable, so I don't know what to do. Is there a way to solve this problem, or are there any workarounds?
You have to redraw the tree itself, or create an empty node and simply remove it when the parent node is expanded.
Personally, I'd go for option b). I've done this before, a while ago and thanks to the events raised by the TreeView it pretty easy to accomplish.
You can give the empty node a value like 'Loading...' so it gives some feedback to the user as well. :)
Add a dummy child node, and remove it when you expand.
Have a look at Josh Smiths excellent tutorial on treeviews. It allows lazy loading of child tree nodes by having a dummy node that is removed upon expansion.
I know the nested set model doesn't pertain to the C# language or LINQ directly... it's what I'm using to develop my web app.
For hierarchical data (categories with sub-categories in my case), I'm currently using something similar to the Adjacency List model. At the moment, I've only got 2 levels of categories, but I'd like to take it further and allow for n levels of categories using the nested set model.
I'm not quite clear on how to use it in a C# context. Here's the article I'm reading on the nested set model. Though this article cleared up my confusion some, I still have a big ?? in my head:
- Is inserting, updating or deleting categories tedious? It looks like the left and right numbers would require re-numbering... what would the LINQ queries look like for the following scenarios?
Delete a child node (re-number all
node's left/right values)
Delete a parent node (what do you do
with the orphans?)
Move a child node to a different
parent node (renumber again)
If my understanding is correct, at all times the child node's left/right values will always be between the parent node's left/right values, am I correct?
Seems easy enough, if only the categories were static... most likely I need to spend more time to get my head around the concept.
Any help is greatly appreciated!
I have a Silverlight project where the main objects are just a bunch of nodes that are joined to each other. A parent node can have many children.
I want to be able to bind the nodes to an itemscontrol or similar and so was wondering how to best structure the parent child relationship.
Is it OK to create a flat top level list of all nodes (List allNodes) and add each node to that, binding the list to the itemscontrol, then on top of that add each node to it's parent's 'childnodes' list to establish the structure - or am I doing some kind of ugly doubling up?
Just hoping there is some kind of best practice or pattern I can latch on to
Thanks
You should use the treeview found in the official silverlight toolkit. Here is an online demo.