Summary of Csla 3.5 stereotypes

Summary of Csla 3.5 stereotypes

Old forum URL: forums.lhotka.net/forums/t/7631.aspx


tiago posted on Tuesday, September 15, 2009

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

tiago replied on Tuesday, September 15, 2009

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

tiago replied on Tuesday, September 15, 2009

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

tiago replied on Tuesday, September 15, 2009

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?

RockfordLhotka replied on Tuesday, September 15, 2009

tiago:

1. The DynamicEditableRoot family is always a case apart.

Yes, they are a little different.

tiago:

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.

tiago:

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.

tiago replied on Wednesday, September 16, 2009

Thanks Rocky, I'll correct the above posts.

david.wendelken replied on Friday, September 18, 2009

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...)

ajj3085 replied on Friday, September 18, 2009

I've done this. You still use BLB and BB, you just override InsertItem, RemoveItem, and Clear so that they throw an exception when called. You'll need a state flag though so that YOU can load the list on fetch though... so your InsertItem will need to check that flag to decide what to do.

RockfordLhotka replied on Friday, September 18, 2009

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.

 

tiago replied on Saturday, November 28, 2009

RockfordLhotka:
tiago:

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> :
Core.
ExtendedBindingList<C>, Core.IEditableCollection, Core.IUndoableObject, ICloneable, Core.ISavable, Core.IParent, Server.IDataPortalTarget, Core.IPositionMappable<C>,
INotifyBusy
where T : BusinessListBase
<T, C>
where C : Core.IEditableBusinessObject

It's also a fact that Csla doesn't restrict what kind of childs ReadOnlyListbBase can have

public abstract class ReadOnlyListBase<T, C> :
Core.
ReadOnlyBindingList<C>, Csla.Core.IReadOnlyCollection, ICloneable, Server.
IDataPortalTarget
where T : ReadOnlyListBase<T, C>

This opens space for having ReadOnlyLists child of a ReadOnlyList. Does it work? Are there problems waiting to be discovered?

 

RockfordLhotka replied on Saturday, November 28, 2009

tiago:

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