There is a tree model as below:
+ItemGroup1
++ItemGroup2
+++Itemgroup3
+++Itemguroup4
+itemgroup5
++Itemgroup6
the sql table :
CREATE TABLE [MM].[ItemGroup]( [Id] [int] IDENTITY(1,1) NOT NULL, [Name] [nvarchar](10) NOT NULL, [Description] [varchar](100) NULL, [ParentId] [int] NULL, [LastChanged] [timestamp] NOT NULL, CONSTRAINT [PK_ProductCategory_Id] PRIMARY KEY CLUSTERED ( [Id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO SET ANSI_PADDING OFF GO ALTER TABLE [MM].[ItemGroup] WITH CHECK ADD CONSTRAINT [FK_ItemGroup_ItemGroup] FOREIGN KEY([ParentId]) REFERENCES [MM].[ItemGroup] ([Id]) GO ALTER TABLE [MM].[ItemGroup] CHECK CONSTRAINT [FK_ItemGroup_ItemGroup] GO
In Using Csla4 book, don't mention to use the switchable object. how can i do to realize the tree model?
You didn't describe your user scenario, only the data model. Although you can sometimes use CSLA to create data-centric objects, I recommend against that.
In many cases, the reason for a treeview is to display a subset of data in the treeview itself, and when the user selects an item in the treeview the result is that another region of the screen is populated with content that either shows more detail, or allows editing of detail. Usually that detail isn't in the treeview itself, but is only in the other region, and only after selection occurs.
I typically implement such a scenario by using read-only objects for the treeview, and then fetching an editable root when selection occurs, so that editable root can be bound to the detail region of the screen.
This avoids the ugly switchable object concept, and also generally provides better performance - because only the small amount of data displayed in the treeview is loaded for the treeview.
I want to create a BOM (Bill of materials) to represent all level material item with tree model... and allow user drag item to change it‘s level or delete item, add item
That's a little tricky with the existing object stereotypes. Primarily because the editable list stereotype assumes that removing an item from the list means you want to delete the item. In your case, removing an item from the list might mean deleting the item, or it might mean that it moved.
So you'll need to add a method to your list class that removes an item without deleting the item. Basically something like this:
[Serializable]
public class Node : BusinessBase<Node>
{
public static readonly PropertyInfo<NodeList> ChildNodesProperty = RegisterProperty<NodeList>(c => c.ChildNodes);
public NodeList ChildNodes
{
get { return GetProperty(ChildNodesProperty); }
private set { LoadProperty(ChildNodesProperty, value); }
}
}
[Serializable]
public class NodeList : BusinessListBase<NodeList, Node>
{
public void MoveTo(Node item, NodeList target)
{
var copy = item.Clone();
Remove(item);
DeletedList.Remove(item);
target.Add(copy);
}
}
Thank your answer, the editable objects how to show tree style in WPF+MVVM? hope you provide a sample in your book using Csla4.0 Silverlight 4 and WPF
The book will use the ProjectTracker sample, so it won't have a treeview, no.
What I like to do with hierarchical scenarios is to read all of the items into a collection object, and then set up non-serialized fields for parent (single) and children (list) for each object which I typically re-establish upon deserialization by running through a quick algorithm.
Tends to allow me to play nice with certain databinding scenarios - this is typically something I have done with read-only collections.
The fact that you mentioned switchable objects seems to say you're editing the hierarchy... in some situations I'd think having a hierarchical object as a single root could make sense, and other cases where it wouldn't make sense.... depends on your use case..
What I like to do with hierarchical scenarios is to read all of the items into a collection object, and then set up non-serialized fields for parent (single) and children (list) for each object which I typically re-establish upon deserialization by running through a quick algorithm.
Tends to allow me to play nice with certain databinding scenarios - this is typically something I have done with read-only collections.
The fact that you mentioned switchable objects seems to say you're editing the hierarchy... in some situations I'd think having a hierarchical object as a single root could make sense, and other cases where it wouldn't make sense.... depends on your use case..
Hi skagen00,
Do you have a sample you can share?
Copyright (c) Marimer LLC