Effector 6.4 developer manual

XML Reference 6.4

Effector Studio 6.4 summary

Effector Studio 6.4 manual

Effector WebAPI 6.4 manual

Effector 6.3 developer manual

XML reference 6.3

Effector Studio 6.3 summary

Effector Studio 6.3 manual

Effector 6.2 developer manual

XML reference 6.0

Effector Studio 3.2 manual

Effector Studio 3.2 summary

Screen addition

We have considered inheritance and its advantages when discussing business objects. As a consequence of its use, the data of the derived class - besides the data of the base class - is stored in the database in a different table, therefore, the data of the derived object can be found in the appropriate tables of the database. However, we have to display such data. Using a grid view, the data can be displayed, but creating two separate EditForms would not be enough to maintain them. It could be done, but it isn't a user-friendly solution. Somehow, we should display the data of the two tables on one EditForm. This problem can be solved by using Fragments. In short, Fragments are the same for EditForm as derived classes for business objects. Each Fragment can be considered is an EditForm supplement attached to a derived object.

Objects and Fragments

Location in the system

Its physical location is in the Editform folder. It cannot be used in itself and cannot be displayed only together with the EditForm, supplemented with the added input fields.


Prerequisites, conventions

The prerequisite of using Fragments Is that the system must know all the available definitions. Therefore, we have to define a list of applicable fragments to each derived object. The list of applicable fragments can be recorded in a special file. The applicable Fragments must be configured in files consistent with their respective object types. The files containing the list of Fragments are found in the FragmentList folder, and following a strict naming convention, their names must be consistent with the following scheme: FragmentList<BOtipus>.xml where the <BOtype> contains the type of the base business object (e.g.: Project, Event, Document, People, Company).


When we derive a ProjectPelda object (BusinessObjectProjectPelda) from the Project object (BusinessObjectProject), we must create a FragmentListProject.xml file containing the references of all the applicable Fragment definitions, as well as a Fragment definition file named FragmentProjectPelda.xml.

Available features

  • FragmentList Fragment list definition
  • Fragment display definition

FragmentList list definition

Following the example above, we create the FragmentListProject.xml file. This can be done in two ways, either by listing the fragment definitions or by entrusting a stored procedure to provide the data. Either way, we will need to take the following steps:

  • We have to create the appropriate file and then set the SourceType and the Source nodes in the following way:
    • SourceType: Its possible values are XML or Database. Obviously, these values are consistent with the two types discussed earlier.
    • Source: Its possible values are Fragment or Database. Please see the examples below.

Definition in static XML:

It can be done by setting the value of the SourceType node to XML. In this case, the possible referenced must be listed in the Fragment node of the Fragments collection. The order attribute must be unique within the file, it contains a simple ordinal number. The ObjectType node contains the type of the derived object. Finally, using the Caption node, we can set the description of the given Fragment type, which will appear in a drop-down list on the interface when a new object is created.


<FragmentList xmlns="http://effector.hu/schema/ns/fragmentlist">
            <Fragment order="1">
                <Caption>Example fragment</Caption>

Dynamic stored procedure definition:

It can be done by setting the value of the SourceType node to Database. In this case, there's no Fragments node in the Source node, and the name of the stored procedure must be specified in the Database node. The stored procedure provides data consistent with the values of the ObjectType and Caption nodes discussed in the above example along a predefined business logic.


<FragmentList xmlns="http://effector.hu/schema/ns/fragmentlist">
            <SelectionString type="StoredProcedure">osp_getProjectTypes</SelectionString>

The input parameters of the stored procedure are provided by the system. These can be used in dynamic evaluations:

  • @mmName VARCHAR(100): Name of the minor menu.
  • @screenName VARCHAR(100): Name of the screen.
  • @componentName VARCHAR(100): Name of the component.
  • @buttonName VARCHAR(100): Name of the button, where applicable.
  • @userID INT: User ID.
  • @parentBoName VARCHAR(100): Type of the base business object.

Its return value contains two columns, which are consistent with the following:

SELECT 'Other' AS [type], 'Other' AS FragmentCaption

Definition of fragment display

Here we can define the controls displayed on the EditForm associated with the supplementary fields of the derived BusinessObject. If the derived BusinessObject does not have a supplementary field, the Fragment definition is still needed, however, in such a case, the file contains only the minimum required settings:

<Fragment xmlns="http://effector.hu/schema/ns/editform">
    <Caption />

In case of a business object with supplementary data, everything is done consistent with the EditForm, as we have discussed it in chapter Edit form. The ControlGroups and all other setting described there can be used.

Important: If there is a ControlGroup definition in the Fragment whose name attribute is identical with one appearing in any of the ControlGroup definitions used in the EditForm of the base/parent object, it will overwrite the settings of the EditForm; thus, it also affects the display of the based object.

Now let’s take a look at the nodes to be used:

  • Caption: mandatory, but currently not in use.

    Example: <Caption>Telephone event</Caption>

  • DataDefinition: It is the reference of the DisplayDefinitionObject related to the base/parent object.


  • BusinessObject: An important difference compared to the EditForm is that here the definition of the BusinessObject must match the following format: ., as seen in the example below.

    Example: <BusinessObject>BusinessObjectEvent.Telefon</BusinessObject>

  • Last update: 1 weeks 5 days ago
  • Effector