JeeWiz Modeler's Help File for RSA/RSM - Dataview Fields Representing a Data Carrier


	The Model-Driven System Builder

JeeWiz Modeler's Help File for RSA/RSM

Contents > 4. Service Data and Operations

4.5 Dataview Fields Representing a Data Carrier

A dataview normally represents a unit of the larger aggregation. A value object is created that can be passed around and manipulated. There are specific places that data passed in the value object can be manipulated. First a filter expression written in Java can be run as the data is passed back from the screen. This is run before any page level validation and can be set up using the filterExpression property. This is usually used to make small changes to the data, such as trimming space or changing case. The expression can refer to the name of the field directly. Perhaps a field called initial might be used to take someone's first initial of their name and you want this stored in the database in uppercase. The filter expression would be initial.toUppercase()

If the data is passed down to the entity for storage another expression is available to the modeler to change the value called the onStoreExpression. The filter expression is more limited but it will fire whether the data is persisted or not (instead it might be displayed on a subsequent page or used in calculations). The onStoreExpression also written in Java is more powerful but will only fire when the data is being sent for update, create or deletion in the database. The syntax here is different. The full value object is available including all field values. The syntax to access the field would be vo.getInitial(). It is possible to construct a field from scratch from other values. For example the readonly VAT field on Order could be constructed as

new Float(0.175*(vo.getNetTotal().floatValue()))

but as you can see Java syntax is not necessarily for the feint-hearted.

An onLoadExpression is available when pulling information out of the database. By having the fields that match to the attributes hidden from the screen and filled in using the onStoreExpression, and unconnected fields only for display that are filled using their onLoadExpression, it is possible to artificially construct fields for display and data entry that differ quite radically from the attributes on the entity used for persistence.

It is also possible to create hooks for an application programmer to do the same thing. By setting the dataviewTriggers property to true on the dataview itself, onStore and onLoad methods are made available to the programmer which allows for even more complex manipulation of the data. This may be preferable if the modeler is uncomfortable putting code within the model or if many of the fields on a single dataview are being manipulated this way.

The value objects carry valid data. Constraints can be added to a dataview field, which will normally be validated after an expression which manipulates the data. The page validation is run after the filterExpression. If page validation is switched off the dataview field validation (and corresponding attribute validation) will be run before the onStoreExpression for those fields that don't have an onStoreExpression and afterward for those that do (so calculations will be based on validated field values).

The same principle holds for fields set as required = true, which is checked at the same time as constraints.

Links: