(r4) XeoPrimerObjectModelReference < WebXEO

WebXEO Web>XeoPrimer>XeoPrimerObjectModelReference (revision 4) (raw view)~~EditAttach~~
-- Main.PedroRio - 30 Jan 2011
---+ XEO Object Model Reference

This section is a reference of all options regarding the creation of a XEO Object Model and it's divided in five (5) parts:
   1 General Model properties
   1 Attributes
   1 OPL
   1 Events
   1 Methods
---++ General Model Properties

In XEO Studio, while editing the general properties of an Object Model, you'll see the following (depicted in figure ModelRef.1)

<img width="768" alt="" src="%ATTACHURL%/General.png" height="896" />

__Figure ModelRef.1 - General Properties Editing for an Object Model.__

Reference of XEO Model General Properties
---++++++ 1 - Name

The name of the XEOModel, this name must be equal to the name of file. This is name that's used when referencing this XEO Model from other XEO Models (like when creating collection attributes, or relation attributes) or the name to be used in XEOQL expressions.
---++++++ 2 - Type

The type of the XEO Model. There are three different types of XEO Models:
   * Object
   * Abstract
   * Interface

The most common type is "Object", which allows you to create instances of the given Model. The "abstract" type represents an abstract Model (much like an abstract class in Java) which allows you to define a set of attributes, events, etc... which you can later reuse in concrete (i.e. type "Object") XEO Models. The Interface type, represents an interface which Models can implement, therefore inheriting all of their attributes and becoming of that type (i.e. if Model A implements interface B, issuing a XEOQL expression of "select B" will return all instances of A, along will all other instances of Models that implement B).

You cannot create instances of Models that are either Interface or Abstract.
---++++++ 3 - Orphan

Determines whether instances of this Model are Orphans or not ( [[XeoPrimerConcepts#orphanConcept][recall from the XEO Concepts]]). An orphan instance is one that can exist by it self, while a non-orphan instance is one that can only exist with a parent instance. Think of an invoice and an invoice line, it only makes sense for an invoice line to exist if it's inside an invoice.

While a Model can be declared an Orphan/Non-Orphan using this property, relations between Models can also change that situation. __See in Attributes__.
---++++++ 4 - Extends

Any Model can extend other Model (single inheritance), inheriting it's attributes, events and methods. Any of those attributes, events and methods can be redefined in the extending Model. In this property you choose the name of the Model to extend.
---++++++ 5 - Description

A description of the Model, serves as documentation.
---++++++ 6 - Label

A label for the Model, it's used throught the application in places such as the "New OBJECT_LABEL" menu in toolbars, when a label of the Object Model is displayed.
---++++++ 7 - Mastertable

The MasterTable property allows you to choose the database table that will hold this Object Model's data (see Database Manager section, also). It can be used for:

   * __Object Models that extend other Models and you want to have all instances in the same table__
   * __Mapped Object Models (from existing database tables)__

__VER ISTO NOVAMENTE__

_
---++++++ 8 - CardID

The CardID of an Object Model is a way to identify it's instances. The name CardID derives from the idea of an Identification Card (or Business Card) that people have. For a person you normally have their name, phone number, e-mail, etc. The CardID property is declared using a syntax which allows to refer to the instance's attributes to compose an "Identification Card" for that particular instance. For example, if Object Model "A" has attributes _name_, _task_ and _age_ and you use the following expression for the CardID:
<pre><verbatim>[name] is a [task]</verbatim>
</pre>

And and instance has the following values for the name, task and description attributes (respectively): "John Smith", "Manager", "30". The CardID for that instance will be:
<verbatim>John Smith is a Manager</verbatim>

If you use the following CardID declaration:
<verbatim>[name] : [age]</verbatim>

The same instance would have the following CardID.
<verbatim>John Smith : 30</verbatim>

*Important*:
   * <strong>The CardID for each instance is a calculated value. It's not stored persitently, as such you can change it as many times as you want while building your application.<br /></strong>
   * <strong>The syntax for a CardID expression is basically the name of an Object Model attribute inside square brackets to refer to their value. Any other character will be interpreted as a literal text.<br /></strong>

_
---++++++ 9 - Extends Java

Every Object Model is converted to a Java class that extends from the netgest.bo.runtime.boObject class. It's possible to make it that the generated Object Model extends from a different class (which, however, must extend from the boObject class), in order to do processing of something in a different way. In order to use that class as the base for the Object Model you'll need to type the fully qualified name of that class.

_
---++++++ 10 - Implemented Interfaces

A list of all the implemented interfaces by the current Model. An Object Model can declare that it implements any number of interfaces (and will inherit all of their attributes and events).
---++++++ 11 - Versioning

Activates versioning for the current Object Model. Whenever an instance of the current Model is saved, if any of its attributes are changed, a new version of the instances is created. The list of versions of a given instance can be seen in an edit viewer of the instance if the <em>renderListVersionBtn </em>property of the [[EditToolBar][editToolBar]] component is true, in that viewer.<em><strong>(PRECISO DE CÁ VOLTAR)</strong></em>

In order to have programatic access to the versions of an object you need to do the following:
   * Retrieve the most recent instance (by loading it)
   * Create a context to hold the prior version (if you use the same context, it will override your instance)
   * Rollback the instance in the new context
   * Load the instance to that new context

Sample code bellow:
<verbatim>boObject        objectVersion = boObject.getBoManager().loadObject(eboCtx, bouiVersion);
            
boVersioning    versioningManager = new boVersioning();
long            bouiOfObject = objectVersion.getAttribute("changedObject").getValueLong();
long            versionOfObject = objectVersion.getAttribute("version").getValueLong();
            
//Create a new context to hold the rollback version
//which means the original object can be left alone
versioningManager.rollbackVersion(newContext,bouiOfObject,versionOfObject, true);
            
boObject        rollBackVersion =  boObject.getBoManager().loadObject(newContext, bouiOfObject);</verbatim>

_
---++++++ 12 - TextIndex

TextIndex will (if active) index all simple type attributes of this Model (integer, string, date, etc...) and will index all simple types of child objects *if* the "appendChilds" attribute is true (and the childs are declared in the "attributes" box. If references to other Object Models are specified you can set how deep the indexer should go and if it should index all attributes or only the CardID of those instances.

The _active_ property activates the indexer for this Object Model.

The _appendChilds_ property activates the indexer for simple properties of the Object Models related through object and collection attributes (they must be declared in the _attributes_ section)

The _deep_ property allows you to choose how deep the indexer will go when indexing attributes of related Object Models.

Attributes - Quais os filhos a indexar e se é só o CardID ou todos os attributos.

<strong><em>CONTINUAR<br /></em></strong>

_

---++++++ 13 - Locale

Defines the Object Model's locale. The most important property is the "Language" property as it defines the language of the XEO Object Model which is used to decide if the labels for the attributes, methods, etc... are retrieved from the Object Model itself or from one of the translation files.
---++++++ 14 - Database Manager

The database manager section has four (4) properties:
   * Xeo Compatible (boolean)
   * Manage Tables (boolean)
   * Manage Views (boolean)
   * Manager Class (String)

This section allows to choose some properties regarding the data source of the Object Model.

The _Xeo Compatible_ option is an option that by default is "true". If false is the value of this property the Object Model is marked as not being XEO Compatible, which means you'll have to provide a value for the "Mastertable" property, for it to know where to retrieve the data. You may also provide a "Manager Class" that will provide the means to access/update the data for this Object Model, or use XEO's default Manager class attempt to provide that for you (não tenho a certeza se é mesmo isto)

The _Manage Tables_ option has _true_ as a default value and if the value is false means that XEO will not create the tables for this Object Model.

The _Manage Views_ option has true as a default value and if the value is false means that XEO will not create the viewes for this Object Model.

The _Manager Class_ option allows you to specify the fully qualified name of a class that implements the netgest.bo.data.IXEODataManager interface which will be responsible for managing data for the instances of this Object Model.
---++ Attributes

[[XeoPrimerObjectModelReferenceAttBase][Common attribute properties]] - Every type of Object Model Attribute has a set of properties which are common between other types. This section explains those common properties.

[[XeoPrimerObjectModelReferenceAttText][AttributeText]] - An attribute to represent a small/medium string of text.

AttributeNumber - Attribute to store numbers of any kind

AttributeBoolean - Represents a boolean (true/false) value

AttributeObjectCollection - Represents a relation to a collection of other instances

AttributeObject - Represents a relation with a single instance

[[XeoPrimerObjectModelReferenceAttBase][AttributeDate ]]- Represents a date (without time) <em>- Does not have special attributes<br /></em>

[[XeoPrimerObjectModelReferenceAttBase][AttributeDateTime ]]- Represents a date (with time)<em> - Does not have special attributes</em>

AttributeSequence - Represents a sequence of values

AttributeBinaryData - Represents generic binary data (usually a file)<em> - Does not have special attributes</em>

AttributeLongText - Holds large amounts of text

AttributeDuration - (Deprecated) - Represents a duration of time.

_
---++ OPL

a
---++ Events

As depicted in figure ModelRef.X, the Events section allows you to define an event and open the editor to type the code of the event.

There are four different types of actions which trigger eight (8) events (each action generates an OnBeforeEvent and an OnAfterEvent)
   * *OnBeforeCreate* (triggered when a new instance of the object model is to be created)
   * *OnBeforeLoad* (triggered when an existing instance of the object model is to be loaded)
   * *OnBeforeSave* (triggered when an instance (new or existing) of the object model is to be saved)
   * *OnBeforeDestroy* (triggered when an existing instance of the object model is to be deleted)
   * *OnAfterCreate* (triggered after a new instance of the object model is created)
   * *OnAfterLoad* (triggered after an existing instance of the object model is loaded)
   * *OnAfterSave* (triggered after an existing instance of the object model is saved)
   * *OnAfterDestroy* (triggered after an existing instance of the object model is deleted)

Note: OnBefore* events are java methods that return boolean. If the return value is false the action (create, load, save, destroy) will not be executed and an error will be generated. OnAfter* events are also java methods, but are void and don't interfere with the instance.

<img width="773" alt="Events.png" src="http://wiki.itds.pt/pub/WebITDS/XeoPrimerObjectModelReference/Events.png" title="Events.png" height="541" />

<em><strong>Figure ModelRef.X - Events editing screen (other options blured to highlight events)<br /></strong></em>

_
---++ Methods

Há ali opções que não faço ideia
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	Events.png	manage	43.2 K	2011-02-01 - 16:51	PedroRio
png	General.png	manage	34.3 K	2011-01-30 - 15:25	PedroRio
Topic revision: r4 - 2011-02-03 - PedroRio
No permission to view TWiki.WebTopBar
No permission to view TWiki.WebBottomBar