|
|
Introduction Implementing Other Uses Background
The base name (without the scope prefix) of the Deck Generator function is used as the title of the generated Deck Template. If the Deck Generator function has a FNC name NME triple, the defined name is used as the Deck title instead.
Fields declared in the WsyDetails and the WsyGrid variables of the Card Generator function will by default be shown as Details or Grid fields in the generated WML Deck Templates.
It is possible to declare that selected Details and/or Grid fields should not be included in specific Cards of the generated Deck Template. This is done by including the omitted fields as local fields in the OmitDetailsFields and/or OmitGridFields variables of the Card Generator function.
Example:
| MyDeck.MyCard | local view VW ...for VAR ...contains SYS |
MyEntity.Update OmitDetailsFields Nonkey |
The result of the declarations above will be that only the key fields of the MyEntity record will be shown as read-only Details fields in the MyCard part of the generated Deck Template.
As in HTTP, the POST and GET Submit methods are both available in WAP. In WML, these two methods each have their own syntax - POST has the parameters specified as name/value pairs while GET requires the parameters to be concatenated in a parameter string. To the WAP user, a POST action will usually appear as a menu point or a push button and a GET action will appear as a link.
The WML code examples below show the same Submit action as represented in a WML Template being implemented with POST and with GET. During execution-time, the replacement markers will be substituted with data values.
Example: WML Code for POST as Submit Method
<do type="accept" label="ObjectName" name="EventHandlerFileName">
<go href="/url/dispathcer.exe" method="post">
<postfield name="WSYD_EVENT"
value="EventHandlerFileName"/>
<postfield name="ImplName2" value="/(ImplName2)"/>
<!-- Hidden-->
<postfield name="ImplName3" value="$(ImplName3)"/>
<!-- Non-hidden-->
</go>
</do>
Example: WML Code for GET as Submit Method
<do type="accept" label="ObjectName" name="FileName">
<go href="/url/dispathcer.exe?WSYD_EVENT=
FileName&ImplName2=/(ImplName2)&ImplName3=
/(ImplName3)" method="get">
</go>
</do>
The default submit method for Details WAP Event Handlers is POST. The Submit method can be changed to GET by adding the following triples:
| MyEventHandler | option NME ...value SYS |
Use post method No |
Grid Event Handlers are always implemented with GET as the Submit method and a link in the Grid table (see also the Grid Event Handlers section in the WAP Event Handler Implementation page).
WAP Event Handlers and Jump functions both result in actions in the generated WML Deck Template. WAP Event Handlers and Jump functions set to Implement No will not be included as actions in the Deck Template.
By default, the label as well as the object name of an action will be set to the unscoped name of the corresponding WAP Event Handler or Jump function. If a FNC name NME triple is specified for the WAP Event Handler/Jump, this name will be used instead.
See also the Overwriting and Omitting Common Template Actions section in the Other Uses of the Card Generator page.
The Deck Template Generator pattern in Websydian determines the WML field label in the following order of priority:
If the WML field label is determined to originate from one of the two possible field labels, the name will be chosen from one of the following items in order of priority:
These rules apply to the generated field labels in the WsyDetails and the WsyGrid variables as well as to the field labels for the user input fields specified in the WsyUserInput variable.
The field labels are left aligned and the field values are aligned according to the alignment triple of the fields. If no alignment triple exists for a field, numeric fields are right aligned and other field types are left aligned.
Each field defined in the local WsyUserInput variable of a Card Generator will appear in the generated Deck Template as user input fields (see the Specify Input Fields in Card section of the Implementing Card Generator Functions page).
By default, user input fields for a WML Card will be initialized by the corresponding WML variables if these exist and have a value. If no value exists for the corresponding WML variable, the value of a user input field will be initialized by the corresponding field in the WsyDetails variable if specified. This happens by substitution of replacement markers when the WML Deck is generated.
In situations where a record is selected from a list in one Card and field values of the selected record may be initialized with the current value and updated by the user in a subsequent Card, the value of the fields to be initialized will not be known at the time that the WML Deck is generated. Instead, the values should be initialized with the WML variables corresponding to the fields, which are set when the record is selected from the list (see the Grid Event Handlers section in the Implementing WAP Event Handler Functions page).
The UpdateArticle Card contains modifiable field values for a record that has been selected from a list in a former Card. These fields must be initialized from WML variables because the values are not known at the time that the WML Deck containing the two Cards is generated.
In order for the user input fields in a WML Card to be initialized with the values of WML variables, the NewContext option of the corresponding Card Generator function must be set to No.
| MyUpdateCard | option NME ...value SYS |
NewContext Yes |
If the NewContext option is set to Yes (which is the default in Websydian Card Generators), all WML variables are cleared and no substitution of WML variables will happen.
WAP devices may only handle WML Decks of a limited size - down to 1400 bytes for some devices. If an application is supposed to support all WAP devices this leaves very little room for designing complex multiple Card structures within Decks.
Online documentation - Websydian v6.1