Cheat Sheet

This is the new layout of CslaGenFork v.4.0.2 (CTP 3)

1. Schema Objects panel "Create" gestures

Only root stereotypes are available. These are the only stereotypes that might include all table columns.
Child stereotypes will always exclude at least one column: the parent ID. Please refer to the TIP below.

Schema Objects gestures.png

2. Columns panel "Create" gestures

All stereotypes are available in 2 sub-menus: Create Editable and Create Read Only.
Note child stereotypes will always exclude at least one column: the parent ID. Please refer to the TIP below.

2.1. Create Editable gestures

Columns - Create Editable gestures.png

2.2. Create Read Only gestures

Columns - Create Read Only gestures.png

2.3. Create child object properties

Each document has a single cover so a child object is the advisable way to do it.


2.4. Create child collection properties

Each document has more than one page so a child collection is the only way to have multiple pages on a document.


3. About Parent Properties

Parent properties are used by the DataPortal_Update method. They should be the Primary Keys of the parent. In this form, CslaGenFork propose all parent primary keys (DBProvidedPK and UserProvidedPK). Usually these are the right settings. You may override these settings, but make sure you know exactly what you are doing.


You shouldn't include Parent Properties in the Value Property collection. Objects aren't database tables and you don't need or should include parent properties. After all they don't belong to the child object but to the parent object (and thus the name "parent" properties).
In the cover and pages example above, DocID is the only Parent Property and it isn't included in cover and pages objects. In case you do need to have access to DocID on the child classes, you can always do it like this:

int myParentID = this.Parent.DocID;

Starting CslaGenFork v.4.0.2 (CTP 3), the create gestures will always refuse to add parent properties to the Value Property collection. Database columns that match both the name and data type of any parent property aren't added to the Value Property collection and a warning is issued.
Very important - For this feature to work correctly, the parent reference (the Foreign Key) column name on the child table must be same as the Primary Key column name on the parent table. Suppose you name the Primary key of the parent table DocID. On the child table, the Foreign Key should also ne named DocID. This means columns on both ends of the relationship shoul have the same name.

4. DataAnnotations validation rules

DataAnnotations validation rules are so much easier to use. On the down side DataAnnotations validation rules:
  • are usable only for validation (and not for transformation)
  • can't be part of any rule chaining
  • can't be part of any rule short-circuiting
  • always use Severity = RuleSeverity.Error
  • always use Priority = 0
  • rule parameters can't be changed at runtime
  • can't run asynchronously
In short, they are useful for simple checks like a field is required.

Let's see a small example. Say you want your users to allways fill a property DocClassName

Validation Attributes settings.png

1) Select the object property you want to be validated
2) Click on the Attributes property option
3) Paste the intended attribute with the intended parameters but leave out the square brackets

In order to use a validation attribute, you must include the DataAnnotations namespace in the class

Validation Attributes usings.png

1) Go to Csla Object Info panel, on the 01. Common Options section click on the Namespaces property option
2) Paste the full namespace but leave out the "using" and the trailing semicolon

And that's it.

Last edited Jul 3, 2011 at 2:08 PM by tiago, version 38


No comments yet.