The following list is plain obvious. I had to do it as I'm rewriting some codegen templates. I thought I might as well shared it. I'll post messages in this thread concerning the child and the parent viewpoints in a while.
Csla 3.5 stereotypes
Objects
- EditableRoot
- EditableChild
- EditableSwitchable
- DynamicEditableRoot
- ReadOnlyRoot
- ReadOnlyChild
Lists
- EditableRootList
- EditableChildList
- DynamicEditableRootList
- ReadOnlyRootList
- ReadOnlyChildList
The following list is plain obvious. I had to do it as I'm rewriting some codegen templates and I feel the templates should check parent child relations and warn the user about no sense combinations. I thought I might as well shared it. I'll post a message concerning the parent viewpoint in a while.
For each group of Csla stereotypes, I list the possible parents.
Objects
EditableRoot
ReadOnlyRoot
parent type 1 = no parent
EditableChild
EditableSwitchable
parent type 2 = parent of editable objects and lists
- EditableRoot
- EditableChild
- EditableSwitchable
- DynamicEditableRoot
- EditableRootList
- EditableChildList
ReadOnlyChild
parent type 3 = parent of readonly objects and lists
- EditableRoot
- EditableChild
- EditableSwitchable
- DynamicEditableRoot
- ReadOnlyRoot
- ReadOnlyChild
- EditableRootList
- EditableChildList
- ReadOnlyRootList
- ReadOnlyChildList
DynamicEditableRoot
parent type 4 = parent of dynamic objects
- DynamicEditableRootList
Collections
EditableRootList
DynamicEditableRootList
ReadOnlyRootList
parent type 1 = no parent
EditableChildList
parent type 2 = parent of editable objects and lists
- EditableRoot
- EditableChild
- EditableSwitchable
- DynamicEditableRoot
- EditableRootList
- EditableChildList
ReadOnlyChildList
parent type 3 = parent of readonly objects and lists
- EditableRoot
- EditableChild
- EditableSwitchable
- DynamicEditableRoot
- ReadOnlyRoot
- ReadOnlyChild
- EditableRootList
- EditableChildList
- ReadOnlyRootList
- ReadOnlyChildList
As you can see, there are only 4 types of parenthood:
- no parent
- parent of editable objects and lists
- parent of readonly objects and lists
- parent of dynamic objects
The following list is plain obvious. I had to do it as I'm rewriting some codegen templates and I feel the templates should check parent child relations and warn the user about no sense combinations. I thought I might as well shared it.
For each group of Csla stereotypes, I list the possible children.
Objects
EditableRoot
EditableChild
EditableSwitchable
DynamicEditableRoot
child type 1 = child of editable object and list
- EditableChild
- EditableSwitchable
- ReadOnlyChild
- EditableChildList
- ReadOnlyChildList
ReadOnlyRoot
ReadOnlyChild
child type 2 = child of readonly object and list
- ReadOnlyChild
- ReadOnlyChildList
Collections
EditableRootList
EditableChildList
child type 1 = child of editable object and list
- EditableChild
- EditableSwitchable
- ReadOnlyChild
- EditableChildList
- ReadOnlyChildList
ReadOnlyRootList
ReadOnlyChildList
child type 2 = child of readonly object and list
- ReadOnlyChild
- ReadOnlyChildList
DynamicEditableRootList
child type 3 = child of dynamic list
- DynamicEditableRoot
As you can see, there are only 3 types of childhood:
- child of editable object and list
- child of readonly object and list
- child of dynamic list
1. The DynamicEditableRoot family is always a case apart.
2. Althought it makes no sense for a ReadOnly collection to have editable childs, how about an Editable collection having ReadOnly childs?
3. Can a collection be the parent of another collection? Or if you put the other way around, can a collection be the child of another collection?
tiago:
1. The DynamicEditableRoot family is always a case apart.
Yes, they are a little different.
2. Althought it makes no sense for a ReadOnly collection to have editable childs, how about an Editable collection having ReadOnly childs?
I don't think this is possible - I think the constraint on C in BusinessListBase<T,C> requires the child to be editable.
3. Can a collection be the parent of another collection? Or if you put the other way around, can a collection be the child of another collection?
Not directly, no. The constraint on C in BusinessListBase<T,C> requires the child to be an editable child - basically a BusinessBase<T> subclass. so you must have intermediate objects between collections.
re: 2. Althought it makes no sense for a ReadOnly collection to have editable childs, how about an Editable collection having ReadOnly childs?
What if I, the programmer, do not want someone (even another programmer) to change which objects are in the list, just edit the objects that are in the list?
What combination would I use then? (I've got that very situation coming up soon...)
It is pretty simple – if you need to save changes, you need to
inherit from BusinessBase or BusinessListBase. If you don’t need to save
changes, you can inherit from the read-only base classes.
The read-only base classes don’t support saving data, because
they are read-only. If you want to save data, they are the wrong base classes
for you.
3. Can a collection be the parent of another collection? Or if you put the other way around, can a collection be the child of another collection?
Not directly, no. The constraint on C in BusinessListBase<T,C> requires the child to be an editable child - basically a BusinessBase<T> subclass. so you must have intermediate objects between collections.
This is an interesting point
It's a fact that BusinessListBase childs must be EditableBusinessObject objects
public
abstract class BusinessListBase<T, C> :It's also a fact that Csla doesn't restrict what kind of childs ReadOnlyListbBase can have
public
abstract class ReadOnlyListBase<T, C> :This opens space for having ReadOnlyLists child of a ReadOnlyList. Does it work? Are there problems waiting to be discovered?
This opens space for having ReadOnlyLists child of a ReadOnlyList. Does it work? Are there problems waiting to be discovered?
Probably not from CSLA - though I guess on the Silverlight side you'd need to test MobileFormatter to see if it can handle that combination.
ROLB doesn't restrict the child type, because you could, if you wanted, use a simple read-only POCO as a child. I used to do that quite a lot before SL came out. Now it isn't realistic, because your object must, at least, inherit from MobileObject - and it is just simpler to inherit from ReadOnlyBase at all times... (to get the automatic serialization with MobileFormatter)
Copyright (c) Marimer LLC