JeeWiz Modeler's Help File for RSA/RSM - How to Construct a Query


	The Model-Driven System Builder

JeeWiz Modeler's Help File for RSA/RSM

Contents > 4. Service Data and Operations

4.8 How to Construct a Query

Constructing a query comes in two parts: the page structure and the dataview structure. The page structure tends to either be an in situ search, for example using a pick styled page which returns the results to the same page, or a search which returns the results in one or more other pages. In the latter case, you will normally need to model the search page itself, the select page, which displays a collection of results, and a general page which displays a single result.

The forwardId should be set on one of the events coming from the search page to point to the other, and the other event needs to be styled search. This will ensure that there is only one search button to return one or many rows. Returning no rows can call the standard message page, which doesn't need to be modeled. This will happen automatically if the search page is styled search. All the code is written automatically, and any business-method behind the search event is likely to be handling data manipulation, for example where the dataview behind the select or display pages are different to that behind the search page. If you choose to replace the standard functionality, the business method the search event will have to call the search functionality itself and route to the correct result page. You may wish to do that if your primary search dataview can't be mapped directly onto a entity.

If the dataview backing a search page isn't the same as that backing the select page or the viewing page, you will need the data to me massaged into the correct format. The easiest way of doing this is to provide a business method hook for the programmer behind the search event. This will let the programmer access the returned values and convert them to the format required by the subsequent pages.

Queries are also created for use within lookups. A user pressing a lookup key will migrate to a standard lookup page based on a dataview that queries in situ. Lookup page structures do not need modeling, but the dataview structures behind them may.

While the gross navigation and styling are handled by the page structure, what data you can query on and what is returned is handled by the dataview structure. As mentioned earlier, the first limitation for standard search functionality is that the dataview must be based on an initial entity. And this is true of all dataviews in the structure.

Queries can be based on one dataview and any dataviews directly relating to them. By default a query will generate on a single dataview and if you want to extend that to include the fields on a related dataview, you have to set the onSearch property on the dataViewEnd on the primary entity which points to the dataview you want included. For example, if your primary dataview is OrderDV which relates to OrderLineDV and you want to be able to search on a field on order line, say quantity: give me all orders by this customer where he ordered more than a thousand of anything, you need to set the onSearch property of the orderLineDV dataview end on OrderDV.

Of course you are might want to ask for all the orders where the customer bought Mars bars. But the "Mars bars" description is on Product and you can only search on directly related dataviews. You can't go from OrderDV to OrderLineDV to ProductDV. There are two possible solutions. First you can shift your primary dataview to OrderLineDV. This is not ideal as you want to return orders not order lines, and you would have to massage to data. Worse, if you are searching on customer name it just shifts the problem as you can no longer access the CustomerDV which relates directly to OrderDV. The second solution is to use dataviews which include related fields, that is fields which are not based on the initial entity but on one related to it. These are readonly fields, and that's exactly what you want. You can then include product description as a field on the OrderLineDV.

You may not wish to make available all fields in your chosen dataview in the query page. You can limit the fields displayed on the query page by setting the onSearch property on the dataview fields. By default the onSearch property on ends is switched off. The rule with fields is that all fields on a dataview that are searchable (that is not hidden and backed by a readable attribute) are made available for a query. Setting the onSearch property on any field on the dataview changes the searchable field list to only include those fields which have the onSearch property set.

In terms of fields returned, you can limit what is shown using style = "hidden" and by setting the OnSummary property. If you explicitly set onSearch on a hidden field, it will be made available to the query but it will not be made available for display or edit. If you set OnSummary, it will be made available on a single record display/edit, but not on a multi-row page, such as is displayed when several rows are returned.

The onSummary property works in a similar manner to onSearch. If no field in a dataview has onSummary set, then all the non-hidden fields are displayed. This can look at little messy, so you can set the onSummary property to select exactly which fields appear in the summary line.

Links: