JeeWiz Modeler's Help File for RSA/RSM - Linking Dataview Fields to Attributes


	The Model-Driven System Builder

JeeWiz Modeler's Help File for RSA/RSM

Contents > 4. Service Data and Operations

4.4 Linking Dataview Fields to Attributes

One of the jobs of a dataview is to link down to the database. This is done both through the entity and directly; in either case the modeled link to the attribute controls how this is done.

A dataview may have an initial entity, if so this forms the basis for any queries and the default storage location. A field with the same name as an attribute on the initial entity is deemed to be linked to that attribute. To link the field to an attribute of a different name on the initial entity, you need to set the relatedAttribute field. If you want to create a field unconnected to an attribute, it can't have the same name as an attribute on the initial entity. This is no hardship as the externalName property can be set so it appears on the screen as though the field has whatever name you want.

It is possible to use wildcard specification to create many fields. If a field is named *, all the attributes will have a field created for them. If a field name ends in a *, extra fields will be added that match the starting characters. For example if the initial entity has three fields companyName, companyAddress, personalAddress; a field called company* will be converted into the two fields companyName and companyAddress.

Primary keys need not be explicitly modeled if their default rendering is acceptable. All dataviews with an initial entity need to be able to manipulate and keep the keys which would be impossible if the key wasn't available. The same is true for fields matched to versionController attributes used in optimistic locking.

As well as connecting to the initial entity it is possible to hook up a field for reading to an attribute on an related to the initial entity. If an entity is related to the initial entity by a to-one relationship, the relationship can be used by setting the relation field to the name of the role/accessor attribute on the initial entity relation. This underlying mechanism does not require a dataview relation that matches the entity relation; it uses the entity relation to form the query. The mechanism allows traversal along more than entity relation. To move onto a second to-one relationship separate the role names by a dot. For example if the Doctor entity links many-to-one to Surgery which links one-to-one to SurgeryAddress, and phoneNo is an attribute on SurgeryAddress, the phoneNo field can be displayed on a dataview whose initial entity is Doctor. If the role/accessor pointing from Doctor to Surgery is surgery and that from Surgery to SurgeryAddress is surgeryAddress, the related property should be set to surgery.surgeryAddress and the relatedAttribute property to phoneNo.

As well as displaying fields that connect directly to attributes on the initial entity and those that connect through the initial entity, those on a dataview directly connected through a dataview relation can also be used, and this is done by modeling the dataview relation.

Remember that is possible to model read/write data access explicitly, so if none of the methods mentioned above give the desired functionality, you should model a disconnected field and code the data access.

Links: