XEO Core is the heart of the XEO Platform and provides the mechanisms to analyze an existing XEO Model definition, create the necessary supporting structures, such as database tables, database constraints, relations between XEO Models, java classes, etc. and runtime environment for the application.

A XEO Model is a representation of an entity. You can declare generic entity properties (such as name, label, etc..) and attributes of several types (text, number, date, boolean, binary, sequence, long text, 1:1 relation or 1:N relation) that represent the entity.

One of XEO's defining features is the possibility to declare behavior for the Model, this behavior will be part of every instance created of that model. If you reuse your Model in another application that behavior will be taken along. Behavior can be declared in several points:

- Instance Events: Instances can trigger a set of events when certain actions occurs during their lifecycle, ex: load, create, save and destroy; you can declare Java code that will be executed before (and after) each of those actions.

- Instance Methods : You can declare methods using Java to execute certain processing, those methods will be available either through XEO's API or accessible in a toolBar when viewing the instance in a web viewer.

- Attribute Behavior and Restrictions : Attributes in any given entity usually have certain properties and restrictions to represent the logic of the entity, like being required, or being disabled under certain conditions. With XEO we can declare the following (using Java):

Validation (code that will run when the parent instance is saved, to check if the current value of the attribute is valid)

Default Value (code that will run when the parent instance is first saved and the value of the attribute was not set)

Requirement (determines whether or not the value of this attribute must be set before the parent object can be saved)

Disabled When (determines when the attribute is disabled (i.e. its value cannot be changed))

Hidden When (determines when the attribute is hidden - this logic is directly associated with the viewers layer.

Formula (determines the value of the attribute, allows calculations and can depend on other attributes, i.e. is recalculated whenever the value of one of the dependents is changed)

Attribute Events: There are a number of actions around events that trigger OnBeforeAction and OnAfterAction events, such as:

Change (When the attribute value changes)

GetValue (When the attribute value is loaded)

Add (When a new instance is added to a collection)

Remove (When an existing instance is removed from a collection)

Change Order (When an existing instance in a collection is re-ordered)

LoadCollection (When an existing collection is loaded into the attribute)

Note that most of the behavior has a direct connection with the web interface. Required attributes will be marked as such, disabled attributes will not be editable, hidden attributes will not be shown, invalid attribute values will be highlighted, formulas will be applied.

When defining an entity in XEO (or any other Object Oriented framework) you'll most probably create attributes whose value must come from a selection of values (typically a list of values). XEO provides the XEO Lov which is essentially a list of values that can be linked to an attribute. This means that the attribute will only accept a value that is available in the list, also the web layer will display the attribute as a combo box to allow such a selection.

Another common requirement when developing an application is to have certain entities that can only exist in the context of a parent (think Invoice and Invoice Line). XEO provides the Orphan/Non-Orphan concept which allows you to determine when instances of a given XEO Model can exist by themselves or have to be created by a parent. The web interface will also adapt to such a situation, reading from the XEO Model definition.

Reusability is a common concern among developers and a key issue to improve productivity. It is very common is Object Oriented Programming allowing programmers to use or extend previous work .XEO Provides mechanisms to reuse XEO Models, by allowing (Single) Inheritance. This means that you can declare a base XEO Model and create new XEO Models by extending the first (inheriting attributes, methods and events), you can also override by redefining an attribute, event or method in the extending XEO Model.

XEO Models have built-in versioning (you can active/deactivate this feature), this means that whenever you save an instance a version of that instance will be created and you can also see the differences between versions in the visual layer.

The content of any XEO Model instance can be indexed to be searched at a later time. XEO provides mechanisms to index the content of some (or all) attribute values for a given instance and index the attributes of related instances as well. This allows you to perform full-text searches on instances with little effort.

One required feature in every application is a permission system to allow only certain people to have access to features/parts of an application. XEO provides a built-in permission mechanism, divided in two parts. A design-time permission system and a runtime permission system:

The design time permission system allows you to specify permissions to read/write/delete/full control a specific instance, while the runtime permission allows you to declare that only a given group/user can have access to instances/attributes/methods of a given XEO Model (access meaning read/write/delete and execute permissions).

XEO Core is also responsible for providing the XEOQL engine, which uses an SQL-like syntax to query instances of XEO Models. The XEOQL engine is used in combination with XEO's Java API to make selections of instances which is mostly used when implementing a XEO Model's behavior (by selecting a set of instances that match a certain condition and processing them). The XEOQL engine respects the permission mechanisms defined in the application.

XEO also provides a batch work mechanism to execute tasks behind the scenes (in a given schedule) using a very simple interface and giving access to the full XEO API.