Elements contains information about the following items in a system:

• Modules – all modules installed
• Objects
  • Belonging to a module;
  • Full definition of parameters with types, restrictions and relations;
  • Object settings – is there any standard print, can it be added to Favorites etc.
  • Object type – is this a normal object, a query or a related object (and if it is a context or a non-context related object);
  • Which is the default template for this object.
• Actions
  • Action code and name;
  • Various parameters of the actions concerning their functions in the application.
• Relations – all relations between objects, the property(ies) used for them, which filters are there to it etc.
• Inheritance – which object inherits which and according to which properties (not mandatory) the inheritance occurs
• Registered event handlers – which object is called by which method when an event occurs. This can happen both for a specific object and for all objects in the system.
• Dependencies when copying records
• Templates for e-mails and printing of records in objects
• Keeping a history of records of which properties of which objects
• Various object setting options – archiving, locking etc.
• Registered web services
• Registered applications that can use the web services of the application This entire information allows the platform to handle and implement the following (yet not only) elements instead of the developer:
• Lists
  • Columns they have;
  • Can rows be edited or can new rows be added to the lists (in-place add/edit);
  • Which columns can be sorted and which cannot;
  • Which columns can be filtered and which cannot.
• Forms
  • How are the fields organized – in what groups;
  • What each field means and which properties of the object does it represent – as well as how they can be recorded and extracted from the field;
  • Linked fields (for example the „City” field is filtered according to the „Country” field);
  • AutoComplete – for example filling in the information in a specific corporate invoice;
  • Mandatory fields and various validations – telephone, Personal Number, Bulstat and other specific checks;
  • Which groups of properties can be loaded to tabs and which cannot;
  • Which lists should appear linked to the form (e.g. Products to an Order would appear in the Order form) and how is the filter created for this list in this context;
  • Enabling or disabling fields according to certain conditions.
• If the user has the right to carry out each task
• Adding, recording and deleting records – everything is managed automatically and the developer does not need to write any code.
• Data validation
• Which are the visible objects
• If a record is deleted, which related records will also be deleted
• How will the menu and system navigation look like
• How does the query for any given template or action look like – e.g. the developer will simply have to request that the “Order.List” action is opened and to define if it should pop up in a separate window or in a tab. The platform will automatically assess if there is such an object, if there is a template List, how to call it etc.
• How to build a given object or class
• How to attach a file to a given object
• What actions a certain object will allow and which of them are considered context-related (require an existing record – such as Delete) and which are not (such as Export data)
• How should the context menu of the object look like – it consists of all actions of objects and all systems included – statuses, archiving, history of properties, locking, lists of all relations etc.
• Which are the related objects to a given object, which of them are context dependant, which should be visible in the form and which should not, how is the filter for each of them executed to receive the record linked to the one, which is currently selected
• Receive a full list of properties of a given object and define what type of field matches each of them.