|
|
Introduction Implementing Other Uses
Basically, Websydian Enterprise WAP works in the same way as Websydian for HTML - only user input fields do also need to be declared specifically in the WsyUserInput variable of the Card Generator function.
Another difference is the way that field parameters are submitted and transferred to WAP Event Handler functions. Input fields are passed to WAP Event Handlers in two ways. Hidden fields are passed directly as values - substituted from replacement markers at Deck generation-time (just like Websydian for HTML) - while user input fields are passed by WML variables which may be changed by the WAP user through direct input or when selecting a row in a Grid table or jumping to a new Card.
Hidden Event Handler fields should be used for fields that do not change during navigation in the WML Deck. Fields changed during navigation are fields entered by the user and fields transferred to WML variables when selecting a row from a Grid table.
In Websydian Enterprise WAP as well as in Websydian for HTML, Integrity Control is applied for hidden fields – see the Using the Integrity Control Module for more details.
This section gives possible WAP-designs for three different situations involving navigation from a table of Grid data. Different situations are explained where navigation between the WML Cards are implemented with either WAP Event Handlers or Jump functions.
The simplest example of an action on a Grid table is a single Grid Event Handler needing no user input in addition to what is already in the Grid table.
Single Grid Events with no user input are implemented by directly calling the WAP Event Handler from the Grid table.
Defining input fields for the Delete WAP Event Handler would involve definition of the key field(s) as input field(s) to the Delete Event Handler function. As shown in the figure above, defining a Grid Event Handler will result in a column of links in the Grid table. See also the Grid Event Handlers section in the Implementing WAP Event Handler Functions page for a similar example.
An alternative design would be to add a separate Confirmation Card from where the deletion could be confirmed. In that case, the action from the Grid would be a Jump transferring the key of the record to be deleted (by defining the key field(s) as local field(s) in the WebInput variable of the Delete Jump function) and a Confirmation Event Handler in the Confirmation Card would then implement the deletion.
Things become a little more complicated when calling the Grid Event Handler involves user input. In Websydian for HTML, this is done by not specifying the relevant input fields as hidden and these fields will then by default appear as user input fields for each row in the Grid.
In Websydian Enterprise WAP, it is not possible to specify input fields directly in a Grid table - and neither would most small WAP displays allow space for that. Instead, control should be transferred to a new Card in which the user input can be entered and a WAP Event Handler subsequently be called:
User input to a Grid Event Handler is implemented by jumping to a separate Card where the user input fields can be entered.
Transferring control from the ‘Grid Card’ to the ‘Input Card’ may be specified by a Jump function or by a WAP Event Handler. If using a Jump to a Card within the Deck, all fields displayed in the Input Card must also be specified in the WsyGrid variable of the Grid Card (though these fields may not be displayed by omitting them from the Grid in the Deck Template). The HTTP server cannot be accessed when jumping from one Card to another and therefore all data must be in correct place when generating the Deck.
If the Input Card is to contain a lot of data fields, it may be considered to implement the Card in a separate Deck. Then only the key fields need to be transferred and a new Deck of data containing all the fields can be generated by the HTTP server by looking up the record in the database.
Yet another alternative design would be to implement the user input fields in the Details region of the Grid Card (by specifying the fields in the WsyUserInput variable of the Card Generator function). But this design may not be neither very obvious nor user friendly.
The most complicated situation is when having several actions related to the Grid and each of these actions may or may not involve user input. In WML, this situation should be implemented by defining a ‘Selection Card’ called from the Grid. This Selection Card should display basic information about the selected record and contain an action (WAP Event Handler or Jump) for each action on the Grid.
The Grid table contains a single Grid action calling a ‘Selection Card’. This Selection Card contains Basic information about the selected record and other Cards implementing the different actions can be called from here.
Whether the Cards should be implemented in a single Deck or in several Decks would depend on how many fields that needed to be displayed in the different Cards. It is necessary to remember that some WAP devices only support a limited number of characters in each WML Deck.
The SelectDeck Utility pattern can be used to implement exactly this situation. The SelectDeck pattern is a Deck function containing a ListCard and a SelectCard function, and WAP Event Handlers and Jump functions can then be added to implement the needed actions.
See also the Limited Size of WML Decks section in the Other Uses of the Deck Template Generator page.
Actions common to all the Cards in a Deck should be specified under the Template function scoped by the Deck Generator.
See also the first two sections Multiple Event Handlers in One Card and Overwriting Common Template Actions of the Card Generator Other Uses page for implementation topics related to WAP Event Handlers.
Online documentation - Websydian v6.5