You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Deprecated

The functionality described in this how-to is deprecated. Please use the Persistency Management guide [editor] instead. 

 

Step-by-step guide

To use a dossier follow these steps:

The dossier plugin consists of two components:

  • a service: com.aquima.plugin.dossier.service.DossierManager
  • a dynamic container: com.aquima.plugin.dossier.container.DossierList

A dossier, for the purpose of this plugin, consists of a profile XML and optionally up to four features and two dates. A feature is a value of type String and can be used to store additional information that should be displayed in the dynamic container. The dates are equal to features, except their type is Date or DateTime. Each dossier has a type, which can be used to separate dossiers as if they were in separate database tables. The type parameter is a required parameter for the service and the container.

Create the dossier manager service

The DossierManager service is used to modify the dossier in the database. A servicecall to the DossierManager requires several parameters:

  1. dossierType*: The type of the dossier. This field is used to separate different kinds of dossiers: the DossierList container also has this parameter, and will only load dossiers of the same type. The type can be any string.
  2. action*: This indicates the action the service should perform. The actions the service can perform are listed below.
  3. dossierIdAttribute*: The Entity.Attribute that contains the ID of the dossier. This attribute should refer to an active instance of the entity during update actions, and should also be present (but not necessarily point to an active instance) during load and save actions. Note that the value of this attribute is set during save actions, it is therefore not needed to manually generate IDs.
  4. transient_entities: A pipe-separated list of entities that do not appear in the profile XML when performing a save action.
  5. undeletable_instances: A pipe-separated list of entities whose instances are not deleted during an init or init-autoset action.
  6. feature1: The Entity.Attribute that should be stored as a feature. Note that this attribute is also stored in the profile, unless the entity is listed in the transient_entities parameter.
  7. feature2
  8. feature3
  9. feature4
  10. date1: Similar to the features, except the type of the attribute should be a Date or DateTime. The attribute is also initialized with the date of today during an init-autoset action.
  11. date2

* = required The action parameter can have one of six values:

  1. init: An 'init'-action clears all instances of all entities from the profile, such that a new dossier can be loaded. The entities which are listed in the parameter undeletable-instances are however not cleared.
  2. init-autoset: This action first calls an 'init'-action, and subsequently, if the date1 and/or date2 parameters are not empty, creates new instance(s) of the attributes specified in the date1 and date2 parameters and fills these with the date of today.
  3. load: A 'load' action loads a dossier from the database. The profile XML in the database is “appended” to the current profile, i.e. the current instances are not deleted. The ID of the dossier that should be loaded should be on Blueriqs requestscope, which happens automatically when the “select” button is clicked in the DossierList container. If the ID is not on the requestscope, the value of the dossierIdAttribute is used.
  4. save: This action saves the dossier to the database. The entire profile is saved to the database, except static instances and the instances of entities which are listed in the transient-entities parameter. As the IDs are generated automatically, the ID of the dossier (specified by the dossierIdAttribute parameter) is updated as well.
  5. delete: A 'delete'-action deletes a dossier from the database. This action does not modify the profile, so if the profile should also be cleared, make an additional call to the DossierManager with action 'init'. Like a 'load'-action, the ID of the dossier to be deleted should be on the requestscope, which happens automatically when the “delete” button is clicked in the DossierList container. If the ID is not on the requestscope, the value of the dossierIdAttribute is used.
  6. update: This action updates the dossier. This means that all active instances in the profile (except the ones specified in the transient_entities parameter) are saved to the database. The ID of the dossier is the attribute specified in the dossierIdAttribute parameter, and is retrieved from the active instance.

An example configuration of the DossierManager service is illustrated below.

Create the dossier list container

The DossierList container is a dynamic container which shows dossiers in a table. The columns of the table are the features and/or dates of the dossiers, and are specified by the headers parameter. The container must have one or two buttons in its containment. The first button should be a “Select”-button and should have an event which is linked to a servicecall to the DossierManager with for its action parameter “load”. This button is duplicated for every dossier, and is used select a dossier. Similarly, the optional second button should be a “Delete”-button with an event linked to a servicecall to the DossierManager with action parameter “delete”. This button is also duplicated on every row of the dossier list.

The container has a number of parameters:

  1. dossierType*: The type of the dossier. This field is used to separate different kinds of dossiers: the DossierList container only loads dossiers of the given type. The type can be any string.
  2. no-result-container: The name of the container which should be displayed if there are no dossiers to display.
  3. headers: A comma separated list of headers for the dossier list table. These headers are used to specify the columns of the table. Each header should have the format [feature]=[message], for example: feature1=Person name. If one of the columns is of a value list type, the value list display values can be used by stating [feature]=[value list name]@[message].
  4. feature1: The Entity.Attribute which should be used to filter the dossiers that are displayed. The value of the attribute is retrieved from the active instance. For example, let this parameter be Person.Name. The container retrieves this attribute from the active instance of the Person entity, for example “Kees”. Only dossiers which have the value “Kees” as feature1 are displayed in the dossier list.
  5. feature2
  6. feature3
  7. feature4
  8. date1: Similar to the feature parameters.
  9. date2

An example configuration of the DossierList container is illustrated below.

 

Unable to render {include} The included page could not be found.

  • No labels