This section provides a quick overview of the structure and schema of CodeFluent design models.
CodeFluent design models can be written in the Free or Normal XML schema form. Even though the global aspect of the model changes from one form to the other, the structure of it remains the same.
The free form is more unformal and convenient for developers to use since it was conceived to be just as writing your business concepts with abstraction of the maximum of technical information. For instance, defining a Customer business concept which has an identifier, a first name, a last name and an e-mail address would be declared as so:
| Entity in the Free Form |  Copy Code |
|---|---|
<Customer> <Id typeName="int"/> <FirstName typeName="string"/> <LastName typeName="string"/> <Email typeName="string"/> </Customer> |
|
On the contrary, the same Customer business concept declared in the normalized form looks like the following:
| Entity in the Normal form | Copy Code |
|---|---|
<cf:entity name="Customer"> <cf:property name="Id" typeName="int"/> <cf:property name="FirstName" typeName="string"/> <cf:property name="LastName" typeName="string"/> <cf:property name="Email" typeName="string"/> </cf:entity> |
|
As you can see, the normal form can quickly get heavier than the free form, however it is best suited if you want to automatically generate CodeFluent models. Accordingly, since the free form is lighter, it's more convenient for a developer to read and write models in such a form.
 |
Note: Microsoft Visual Studio can only provide auto-completion for the normalized form. However, Normal and Free schema forms can be mixed in a common CodeFluent model and both ways are completely equivalent to the CodeFluent parser. |
Regarding the structure of a model, the first steps is that one needs to declare the root node named Project. Inside a Project node, the following nodes can be declared:
- Import nodes to import other parts,
- Entity nodes representing a business concept of your project,
- Enumeration nodes representing a static enumeration of values,
- Rule nodes representing business rules at the project level,
- Message nodes to declare strings at the project level,
- UserType nodes to declare user defined types,
- Category nodes to declare UI compartments,
- Store nodes to declare Persistence compartments,
- Pattern nodes to declare patterns,
- Producer nodes to setup producers.
Then inside an Entity node, the following nodes can be declared:
- Property nodes to declare properties of your business concept,
- Method, Snippet or SetSnippet nodes for methods (which can contain Parameter sub-nodes),
- Rule nodes representing a business rule for the current entity,
- Message nodes to declare strings at the entity level,
- View nodes to declare a view on the current entity (a view can contain ViewProperty sub-nodes),
- Instance nodes for entity instances.
|
For more information on Producer nodes, go to the Generating section. For more information on Pattern nodes, go to the Aspect Designing section. |
This is a quick overview of possible nodes contained in a CodeFluent and should not be taken as an exhaustive list of all possible nodes in a CodeFluent model.
To know more on the model structure, possible nodes and their attributes, please refer to the Reference Guide.
In This Section
Information about CodeFluent design concepts, CodeFluent design model and CodeFluent types.
Information about the Project concept and design model exploration.
Information about the Entity concept (standard and light), instances, relationships between them (e.g. inheritance, composition, or association), how to group entities (into namespaces, schemas, categories or stores), and finally information about directory entities (e.g. User and Role).
Information about the Property concept (standard and computed).
Information about the Enumeration concept.
Information about the Method concept: persistence methods such as Load, Search, Count, Delete, as well as snippets.
Information about the Rule concept.
Information about the View concept.
Information about the Message concept.
Control produced names by using naming conventions.