5.12 How to Tweak the Data

The "standard" way of passing data between the screen and the database works something like this:

A query screen is filled in and a search event fired. The data is passed from the screen to the page processing code, which in turn constructs the part of an SQL query that depends on the data entries. This is passed to the dataview object in the application server which marries it to the part of the SQL query that doesn't depend on the data (such as what fields are to be returned from which tables, and how the tables are related.

This query is run on the database, and the results passed up to the dataview object. This passes it up in turn to the presentation layer which stores it in the http session. If there is only one result returned, there is another call to the database to get all the related dataview field information before it is stored in the session. The next page is called which takes the values from the session and displays it.

If the user edits the data and updates it, once again, the information is sent to the presentation layer for processing, where it is validated. If validation fails for any field, the failure messages for all fields are aggregated and displayed on the screen. If there are no failures the data is passed to the dataview object where it is checked again against the constraints. This happens in case data has been passed into the dataview object by background programming which has circumvented the presentation layer validation. If the dataview is handling a value (transfer) object which contains data for several entities, it splits these up by sending them for processing to other dataviews. When it sends information pertaining to its own initial entity to that entity for storage, the entity runs persistence level constraint validation, before storing the data. Failure at the level of either dataview or entity will cause the first error encountered to be passed back to the presentation layer for display.

There are several points where the data can be altered. Query data will not normally be altered at the presentation layer. (See "How to build a query" for modeling options); however, the data independent part of the query can be modified at the level of the dataview. There are three dataview properties available to help you modify the query. First the sqlOrder property, which alters the return order. Second the additionalWhereClause, which adds a further restriction to the query, and finally the sqlStatement, which replaces the whole query lock, stock and barrel. This last option should really only be used where you expect the dataview to be used for a single query in one particular place.

Also of interest is the dataviewTriggers option. This allows the application programmer to replacing the method of data access entirely using the overrideDataRetrieval method. Two other methods are given to the programmer with this option, onLoad and onStore.

Following the query, the data is returned. The onLoad method is run if the dataviewTriggers option is set. There is also an onLoadExpression, which can be set by the modeler as part of the return of the data. The expression is places on the field modifying the returned data, while the onLoad method is written by the application programmer against the whole value object and can be used to alter any of the values. If only one or two fields need small alterations, then by all means use OnLoadExpressions if you want, but as soon as it starts to get complex, it is a good idea to enable the onLoad method.

It is worth noting that there is an entityTriggers property on an entity which also enables an onLoad and onStore method on the entity, by this onLoad does not fire for a standard query, which bypasses the entity and calls directly from the dataview to the database.

There are alteration points following an update (or creation) too. The first that fires is a filterExpression. This is placed on a field and modifies the data at the presentation layer level, before the presentation validation. The second is the onStore method at the level of the dataview. Then the onStoreExpression at the level of the dataview field, both this and onStore running before the dataview validation. Finally the entity level onStore method.

All these different hooks can be used for slightly different things. Changes at the level of the presentation layer should be used to rectify input formatting, such as trimming spaces or changing case. Changes at the persistence (entity) level would normally only be specified if several dataviews all update a table through the same entity or if the data must look one way to the application, but for legacy reasons it must look another way to the database. For data changes due to business rules, the dataview/service level is the right place to action the alterations.

• How to model the application data structures

Copyright © 2001-2006 New Technology / enterprise Ltd.