My data comes from a database. I have an item data table with some basic properties.
Item
{
ID,
Name,
Description,
...
}
Then I have a many to many relationship table with:
Parent
{
ParentID,
ChildID
}
I'm iterating through each item and displaying its children; and its children's children, etc. I assume this would best be accomplished with nested repeaters, but I could be wrong.
How do I get multiple heirarchical levels using asp:repeaters? I've only ever used one nested repeater, I have no idea how to do 3+.
Personally I probably do this by creating a custom control with an Item property and some sort of either Parents or Children property. The control would display details on Item, and then use a repeater to show each element in Parents / Children, where for each item the repeater recursively uses the same control to render the item.
I would do what #Kragen said. But if you really think that creating two components is too much you should use one repeater and two foreach loops in on data bound.
Using two repeaters one inside of another is overcomplicated not to mention 3 repeaters :).
A Parent-Child relationship, which is many-to-many? This doesn't make sense, at least calling them a parent and a child doesn't make sense. If it is really many-to-many, it's a network, if a child only has ONE parent, then it is a hierarchy.
With the former, I'm not sure visualizing them in that way is any good. How do you visualize a child with more than one parent?
With the latter, why not use a TreeView with a custom item template? It handles all the hierarchy stuff automatically. The problem with repeaters is that if you are not doing them dynamically (creating them in code), then the level of nesting is fixed and you cannot go as much as you want. Doing them dynamically would work, but would bring overhead.
I'm not very sure what exactly you are trying to accomplish. Maybe providing some more details about the end-result you need to see would be helpful.
Related
I'm creating some custom object using ContentControl and by adding them to toolbox allowing user to drag/drop them on a page. Now, I'm facing a situation where some of these controls have children. In case it is only one item without children I retrieve each object's id in Tag property, however, for the 2nd category this won't be the case, since I need to store and retrieve a hierarchy set of IDs. After few searches I ran into MSDN forum and it is almost close to what I need to do but I was wondering there are better and more optimized methods of implementation.
Any help will be appreciated.
Thanks.
If an object can have more than one child you use an ItemsControl and not a ContentControl. And an ItemsControl containing ItemsControls is a hierarchy.
Background
I have a TreeView that follows the MVVM design pattern and supports multiple selection by recording TreeViewItem selections in a List. As it stands there are several types of TreeViewItems available for the user to select.
They are:
Two Root nodes of type WorldFolder and MyDataFodler which can contain child Folder types
Child Folder nodes of types LocationFolder, PersonFolder, CollectionFolder
Child Item nodes of type LocationItem, PersonItem
CollectionFolder can contain child nodes of Folder types
In all this works very well with very little code and supports collections of Locations and People and furthermore Collections within Collections.
Problem / Question
My top level view-model keeps track of the selection state of TreeViewItems and the current selection may be a combination of Item, Folder or even Root type nodes. Depending on the user's selection I want to create a dynamic ContextMenu. So far this works! When I select several LocationItem and/or PersonItem type nodes my view-model generates a custom ContextMenu. The problem is the complexity! My view-model is quickly turning into dozens of if/else if/else statements to capture all the possible permutations!
For example:
if (_selectedItems.All(item => item is PersonItem)) // Only people selected
{
// Create ContextMenu based on only PersonItems
}
else if( _selectedItems.All(item => item is LocationItem)) // Only Locations
{
// Create ContextMenu based only on LocationItems
}
...
Is there a better way to handle all the possible permutations of user choices and generate my ContextMenus more efficiently?
* Sorry about the code formatting, it's been giving me grief all week *
I can't remember where I read this wise saying:
The best way to work with a TreeView is not not to work with the TreeView
What does this mean? Move the functionality into the tree nodes and keep the tree view as thumb as possible. Unfortunately, by default the tree node does not many events, though, it's easy to redirect the tree view events to the nodes.
Once done, you can override the ContextMenuStrip property in your nodes. The first selected node creates the list of ToolStripItems it wants to handle and asks the tree view which are allowed (e.g. with a FilterMenuItems(desiredItems) method). The tree view asks all selected nodes which of the nodes they would be able to handle. The result is your context menu.
This should work with almost any count of different nodes and keeps the tree (nodes) easy to maintain.
Edit: Dang! Missed the WPF tag, so I cannot asses the available events, since I did not yet work with WPF
I have a productVariant object which has child product object. I want to show the value in the DataGridView, can anyone let me know how to do this?
Here is the structure of the object.
I tried to bind "ProductVariant.Product.Name" to the DataProptertyName in the DataGridView, however, it did not not showing any value.
Can anyone help with this? Many thanks.
DataGridView-controls can not bind child objects automatically.
If you are working with Win-forms, my suggestion would be to create two Dialog windows.
One is for parent-objects(with a DGV) and another is for child-objects(with a DGV).
When the user opens the parent window, parent objects would be loaded row-wise in the DGV.
Then if the user double-clicks a row on the parent-window, the child-window would be shown up and the child objects of that parent would be populated on the DGV on the child window.
In this way you can keep things clean no matter how deep the parent-child relationships go. Moreover, add, edit, delete, etc. operations would be much cleaner.
You can also use some third-party controls like, HierarchicalDataGridView.
WinForms binding does not allow traversal of nested properties, though such a thing is possible in WPF. The easiest solution for WinForms is to add a property at the top level (the actual type being bound) that represents what you want to bind--ugly, I know.
You could implement a custom TypeDescriptor and provide a PropertyDescriptor that does the same thing. This is the cleanest solution as far as what gets exposed outside of the class, but it's a non-trivial amount of work.
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.