JeeWiz Modeler's Help File for RSA/RSM - How to Model a Styled Page with Styled Events


	The Model-Driven System Builder

JeeWiz Modeler's Help File for RSA/RSM

Contents > 5. User Interfaces

5.4 How to Model a Styled Page with Styled Events

Once you have added a page you can attach pre-built functionality by adding a style to the page. The functionStyle of page may influence the layout, what appears on the page and how it is handled. It also may influence what style of events the page can link with. In most cases function styles require an initial entity backing the dataview.

You can also restrict function by setting the accessStyle to readonly, but few function styles support it.

The menu style can be used to influence the menu position. This only affects tlr menus and influences whether the item appears on the left or right hand side menus.

The search function style creates a page designed to create a query. The fields displayed on the page may differ from those on the equivalent basic page (see How to construct a query) and the form of the field itself may differ in order to accept queries such as >05/10/2003 or not null, which can't be input into a dropdown or a checkbox. Relations too will display differently. A search page requires a search event to come from it to actually run the query. The search event should have two modeled destinations, one going to a select page and one to the processing page. The first one should be the main event, styled search, that will fire if only a single row is returned against the search criteria. The second modeled event should have its forward-id slaved to the master event and will be picked up as a destination if more than one row fulfils the search criteria.

The select page displays the summary fields of multiple rows, each row terminated by a select button which takes the user to a single record (typically basic) page for edit or display. To model the page that this leads to, use a select style event. If the dataview behind the select page is not the same as the single record page the event will have to have code behind it which converts the form of the selection to that of the subsequent page. Select pages don't require an initial entity.

A pick page combines the functionality of search and select. The top part of the central section of the page contains the search fields, the bottom part contains returned rows. There is no need to connect a search event to the pick page as the results are returned within the page, but a select event should be modeled to lead to the single row page used for editing. Unlike with a select page, there is an opportunity to go to different pages for edit and display. The select event will take the user to the edit page and a readonly event can take the user to a display page. If you want the same event to connect to both the edit and display buttons, you can style it select,readonly. Basic pages can be run in readonly mode, and this will be triggered automatically when attached to from the readonly button.

Other features of the pick page include the ability to only return a limited number of rows, to page through the dataset (forward or backward) each time returning only the requested number of rows, and to sort the results of the query by column. This comes as standard and the modeler need not specify anything special.

Create pages don't support readonly mode and don't display most grid types (the exception being assocgrid). They start out with mostly blank data items, populated only with default values and connect to a create styled event which validates the data and saves it to the database. Obviously this requires an initial entity behind the dataview.

Assoc (associated), list and listadd pages are used to link multiple rows of data to a master dataviews row. This is to implement a one-to-many or many-to-many relationship. The information on the master row can be created or updated on one page and the information on the subsidiary rows created, edited, linked or unlinked to the master row on the subsequent assoc, list or listadd page. The changes made on the page do not get reflected on the database immediately to allow several pages to follow one another and all changes to be made at the end. These page styles are designed for use with wizard pages and tab sets, but can be used elsewhere. They all need a masterDataView property set.

Assoc pages display multiple rows, all rows from the table behind the initial entity of the dataview. There is also a checkbox against each one, which if selected link the row to the master row. This should be used only when there are few rows in the table, and gives an alternative presentation to having the master row appear with a related assocgrid.

Listadd pages create, delete, display and manipulate rows which are linked to the master row. All linked rows appear at the bottom of the central section. The top of the central section of the page gives an area where data can be entered and a create button can then be used to create the linked row, which adds itself to the list at the bottom half. Any row in the list can be selected for editing, at which point the data will be transferred up to the top section. This can be "saved" into the linked row.

List pages select rows that have been created elsewhere and link them to the master row. They can be used to unlink the rows as well as link them. Like listadd pages, linked rows appear at the bottom of the central section. Use listadd on one-to-many if the subsidiary rows will normally be created especially for the master page (like order lines on an order) but use list if the data is just being associated with the master row (like a club member booking a function room). List will often be used on a many-to-many relationship if there are a large number of possible rows.

Unlike assoc and listadd pages, the list page displays the summary fields of master dataview by default above the linked rows. It is also possible to define inline events coming from a list page which add buttons to each row rather than at the bottom of the page. These can then be used to select the row in a similar manner to a select page or select grid.

Lookup pages are not modeled as pages at all! They are created automatically if needed and called as part of other functionality, such as the list page, which uses a lookup to find the row it is adding, a group of lookup fields, which add data onto a page from somewhere else or a lookup relation.

Tabbed page sets are not currently available for modeling and are only available as maintenance pages. They are created by setting the style of an entity or dataview to "tab".

Event styles:

create This is used as part of a direct session method call (mostly used internally) to ensure that relationship links are correctly defined within the dataview changes hierarchy. It will also clear the value object so a return to the same page will not redisplay the previously entered data. Validates.
delete Used in a similar way to "create" to ensure the correct dataview change relationships. It clears the value object and is disabled on readonly.
update Validates.
search Used to link a search page to a select page.
select Used to link a select or pick page to a maintenance page.
readonly Used to link a "pick" page to a "readonly" page.

display Style:

inline Do not render the button at the bottom of the screen. "select" events are never rendered as buttons at the bottom of the screen and are inherently inline. List pages create buttons to initiate these events.

Links: