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
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
2.1. Create Editable gestures
2.2. Create Read Only gestures
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.
- 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
. 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
1) Select the object property you want to be validated
2) Click on the Attributes
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
1) Go to Csla Object Info
panel, on the 01. Common Options
section click on the
2) Paste the full namespace but leave out the "using" and the trailing semicolon
And that's it.