UNIFACE 8.1.01 - Details on How To Develop a Three Tier Application
Note: The term Business Object Model is named 'Application Model' in the UNIFACE Beta release.
Fast Start-up
Create The Business Object Model:
- Execute 'Load Definitions' on an existing database. Or:
- Import a UNIFACE 7 application model. Migrate it. Or:
- Create a Business Object Model yourself in the UNIFACE development environment.
What Happens: For each entity, an 'Entity Abbreviation' is generated in either way. The entity abbreviation is by default composed out of the first 13 characters of the entity name.
Entity abbreviations must be unique across the whole repository, because component names are derived from it (13 characters + 3 letter postfix that indicates the component type).
!!! UNIFACE does not (yet) check, nor warn you about duplicate entity abbreviations !!!
The entity abbreviation can be edited at the 'Define Entity' form.
Next, generate component subtypes, in order to tailor entities for use at a particular component type. Before generating subtypes, make a choice whether session services should delegate Data Access and Business Object Behavior to entity services. This choice should be reflected in the default SSV subtype. See: Customizing The UNIFACE Defaults.
Goto the 'Define Business Object Model' form. Select your Model.
Select menu: Edit -> Generate Component Subtypes
Generation of component subtypes may take a while [UNIFACE beta: progress indicator not yet available].
What happens: For each entity, a set of component subtypes is generated. Fields are replicated, as well as the relationships. The component subtype name is derived from the supertype's entity abbreviation and postfixed with a three letter 'component type' abbreviation.
Each component subtype contains the same fields and the same relationships as its supertype.
Editing Yourself
Component subtype properties and triggers are filled from blueprint defaults. See Customizing The UNIFACE Defaults for which defaults are supported.
Component subtypes can be generated for a complete Business Object Model, or per individual entity.
Component subtype generation for a complete model is accomplished from the Define Busines Object Model form:
Edit-> Generate Component Subtypes
Component subtype generation for individual entities can be invoked from the Define Entity form (supertypes), or from the Define Functional Subtype form:
Edit-> Generate Component Subtypes
There is a preference for component subtypes creation:
Utilities-> Preferences-> Model Editor
Component subtypes (including their fields) are fully editable in terms of properties and triggers, except for those properties relating to the physical database structure (data type, packing code).
Fast Start-up
For each business object, edit business logic in the SSV subtype or in the ESV subtype (depending if entity services are to be called from session services).
Generate entity services: If you want to make use of entity services, generate them as follows:
Goto the 'Define Business Object Model' form.
Select menu: Edit-> Generate Entity Services
What happens: For each ESV subtype, an entity service is generated. The name of the entity service is derived from the ESV subtype's parent's abbreviation, extended with the postfix 'ESV'.
Entity services are generated from a default component template, named UESVDEF. Entity services inherit component level properties and triggers from UESVDEF.
On the entity service, the ESV subtype is pasted in the component structure. Thus, entity level and field level properties and triggers are inherited from the Business Object Model.
Entity services are compiled after they are generated.
Note: If you already had components with a name equal to an 'ESV subtype name extended with postfix ESV', then these are overwritten.
Now, generate session services as follows:
Goto the 'Define Business Object Model' form.
Select menu: Edit-> Generate Session Services
What happens: For each SSV subtype, a session service is generated. The name of the session service is derived from the SSV subtype's parent's abbreviation, extended with the postfix 'SSV'.
Session services are generated from a default component, named USSVDEF. Session services do not inherit component level properties and triggers from USSVDEF, since USSVDEF is not a component template.
On the session service, the SSV subtype is is pasted in the component structure. Thus, entity level and field level properties and triggers are inherited from the Business Object Model.
Relaltionships in which the SSV subtype participates as a 'one' or as a 'many' are pasted as inner 'up' and inner 'down' entities. This enables referential integrity management.
Inner entities are customized at the session service. For example, an inner 'up' entity does not contain 'write' in the WRITE trigger. In order to cater for this, USSVDEF contains specific defaults for this purpose.
The session service contains some default operations: load() and save(). These can be invoked by a presentation component.
load() expects an XML profile, retrieves data and returns the expanded data in an XML stream.
save() expects an XML stream, 'reconnects' the data to the database, saves the updates and returns the updated stream.
[UNIFACE beta: no validation or error checking is incorporated in this code].
During the generation of a session service, the DTD required for the implementation of the load() and save() operations is also generated. The DTD is based upon the session service's structure. The DTD name equals the session service name. The DTD contains a 'default mapping', in order to map SSV subtype data as delivered by a session service, from/to USP subtype data as present at an USP [UNIFACE beta only - UNIFACE GA will contain mappings defined for each component, as a #Define].
In order to make these operations work, a #Define is generated into the session service Defines trigger:
#Define MyDTD=...
For each session service to be generated, you can choose if all fields need to be painted, no fields need to be painted, or you can select which fields need to be painted [UNIFACE beta: selecting the fields yourself, does not work properly]. This drives the generation of DTDs and (later) the default paint as shown on presentation components. Foreign key fields are not painted by default.
Session services and DTDs are compiled after they are generated.
Editing Yourself
Re-generating Entity Services
Why: Processing a change in the structure of an Business Object Model.
How: Entity Services can be generated per Business Object Model, or per ESV subtype.
Re-generating Session Services
Why: Processing a change in the structure of an Business Object Model.
How: Session Services can be generated per Business Object Model, or per SSV subtype. Note that DTDs are also changed.
You can can choose to preserve proc written for the session service. This applies to generated entities, as well as for entities you added yourself. However, in case of the latter: You need to re-paint the entities yourself. Upon re-painting, Proc code is restored.
Creating more DTDs for a Session Service
Why: Generally, each client of an SSV is only interested in just a portion of the composite structure.
How: From within the session service component editor, select Edit -> Create DTD From Structure. Next, from within the component editor, goto the DTD editor by first selecting Editors -> Model. Open the model of interest and subsequentially select Goto -> DTDs from within the Define Business Object Model form. Edit the DTD by adding entities/fields and by removing entities/fields which are not of interest.
Alternatively, goto the DTD editor directly and duplicate the DTD as generated from the SSV. Remove entities and fields which are not of interest.
Creating more Entity Services
Why: It is recommended not to do this. There is already one ESV for each ESV subtype. It does not make sense to create another one, because it would contain the same busines logic.
Also, if ESVs are re-generated after a change in the Business Object Model, extra manually created ESVs or migrated UNIFACE 7 object services are not considered (unless they would have had the same name as the generated entity services - then they are overwritten).
Creating more Session Services
Why: Principally, this action should not be necessary. For each SSV subtype, there is a session service on which it plays the role of an outer. It also appears on session services as inner-down or as inner-up. Thus, data related to the SSV subtype can be obtained in any format. Consider also the case 'Creating More DTDs for a SSV'.
However, it is still possible to create your own session service.
How: Start-up the session service component editor. Either paint entities and fields yourself, or use the Edit -> Create Structure from DTD.
Updating Business Logic for Single Business Objects
Why: A change in business logic ...
How: Edit the relevant ESV or SSV subtype in the Business Object Model. Re-compile just the entity service on which the ESV subtype is painted, or all session services on which the SSV subtype occurs.
Updating Business Logic for Composite Business Object Structures
Why: Any reason.
How: Edit the SSV subtype or the relevant session service. Re-compile all relevant session services.
Updating 'Data Access' for all Session Services
Why: Any reason.
How: Component subtypes cannot (yet) be re-generated. Use Global Updates for managing the Data Access property for all SSV subtypes in one go.
Updating Entity Service Component Operations
Why: Any reason.
How: Preferably edit the component template UESVDEF. Re-compile all entity services.
Updating the Structure of an Business Object Model
Why: Any reason. A change to the Business Object Model consists of either of the following:
- a model entity has been inserted
- a model entity has been deleted
- a field has been inserted to a model entity
- a field has been deleted from a model entity
- a relationship has been inserted
- a relationship has been deleted
- the delete constraint of a relationship has been modified
How:
Ad 1.: First generate component subtypes for that entity. Next, generate an entity service for that entity. In case the entity participates in relationships: re-generate all session services. If not, then just generate a session service for the entity itself (i.e. for its SSV subtype).
Ad 2: First delete its entity service. If the entity participated in a relationship, then re-generate relevant session services as well, or edit relevant session services yourself.
Ad 3: Re-compile its entity service and re-compile session services. Optionally, re-compile UNIFACE presentation components.
Ad 4:Same as 3.
Ad 5:Re-generate and re-compile session services Alternatively, edit and re-compile relevant session services yourself. Note: changes made to a relationship are kept in sync for the entity's component subtypes.
Ad 6:same as 5.
Ad 7:same as 5.
Fast Start-up
A set of forms or server pages can be generated from the Business Object Model. [UNIFACE beta: server pages only, no field labels are generated yet. Form are not yet generated]. Pre-requisite: session services are already generated - DTDs as generated during session service generation are used for form or server page generation.
For each business object, edit presentation logic in the FRM or USP subtype.
Generate Forms or Server pages as follows:follows:
Goto the 'Define Business Object Model' form.
Select menu: Edit-> Generate Forms
Select menu: Edit-> Generate Server Pages
What happens: For each FRM (USP) subtype, a form/server page is generated. The component name derived from the subtype's parent's abbreviation, extended with the postfix 'FRM' ('USP').
Forms and server pages are generated from a default component, named UFRMDEF (UUSPDEF). Component level properties and triggers are not inhertited, since UFRMDEF (UUSPDEF) is not a component template.
On the form, the FRM subtype is generated. On the server page, the USP subtype is painted. Thus, entity level and field level properties and triggers are inherited from the Business Object Model.
The DTD as used for the related session service is pasted. Thus: fields and inner entities show-up as on the related session service.
The server page contains some default operations: clear(), load(), and save(). The former two can be access directly from a browser; the latter needs to be accessed via a button, resulting in executing a 'SUBMIT' to the webserver. [UNIFACE beta: buttons need to be painted by yourself, UNIFACE 8101 GA will do this for you by using a blueprint component UUSPBUTTONSDEF and UUSPMENUDEF].
In order to make these operations work, some #Define statements are generated into the component's Defines trigger:
#Define MyDTD=...
#Define MySSV = ...
Forms and server pages are compiled after they are generated.
Editing Yourself
Creating a new Server Page or a New Form
As in UNIFACE 7. However, you can fastly create a paint by selecting the menu: Edit -> Create Structure From DTD in the component editor. Your are asked about subtype conversion. This, because the DTD is owned by the session service and thus contains a structure with SSV subtypes. These are not the ones you would like to see on your server page or form. UNIFACE can transform SSV subtypes to USP subtypes or FRM subtypes, depending on the component type you are working at.
Also check the previous section on XML mappings.
UNIFACE defaults are used when new objects are created in the UNIFACE repository. For example, there are defaults for creating a new form. Defaults in general are described in the document 'The Enhanced UNIFACE Development Environment' (see the index). This chapter describes some specic customizations for developing three tier applications.
Supported defaults for model entities and fields are located in the Business Object Model 'U'. They apply to component subtypes, as well as to functional subtypes.
The following defaults are available:
USUPERTYPEDEF.U
UFUNCTIONALSUBTYPEDEF.U
UCOMPONENTSUBTYPEDEFFRM.U
UCOMPONENTSUBTYPEDEFSVC.U
UCOMPONENTSUBTYPERDEFPT.U
UCOMPONENTSUBTYPEDEFESV.U
UCOMPONENTSUBTYPEDEFSSV.U
UCOMPONENTSUBTYPEDEFUSP.U
Edit defaults for functional subtypes by Goto -> Functional Subtypes from the 'Define Entity' form.
Edit defaults for component subtypes by Goto -> Component Subtypes from the 'Define Entity' form.
Each of these default entities has a blueprint default for a field:
UFIELDDEF.USUPERTYPEDEF.U
UFIELDDEF.UFUNCTIONALSUBTYPEDEF.U
UFIELDDEF.UCOMPONENTSUBTYPEDEFFRM.U
...
The following entity properties are copied from the parent [UNIFACE beta: none - all entity properties are copied from the defaults]:
All other entity properties are copied from the defaults.
The following field properties are copied from the parent [UNIFACE beta: all field properties except for data type and field interface are copied from the defaults]:
All other field properties are copied from the defaults.
Entity and field triggers are copied from the defaults. If a default trigger is empty, then the subtype will inherit from its parent.
The following default 'bluerint' component are available:
Each component contains an a default entity for 'component variations on a model entity', as well as a default 'dummy entity'.
SSVDEF contains additionally defaults for inner-up and inner-down entities:
Goto the 'Define Business Object Model' form. Select model 'U'.
Press Entities button. Select Entity USUPERTYPEDEF.
Select Goto -> Component Subtypes
Select UCOMPONENTSUBTYPEDEFSSV
Set the Data Access property so that it reflects your choice. Fill-in a dummy Entity Service - it will be overwritten upon session service generation (not when you define a session service yourself !).
Note: This action needs to be executed before Component Subtypes are generated, because re-generation of Component Subtypes is not (yet) supported.