Other Uses of the Deck Template Generator

Introduction     Implementing    Other Uses     Background

• Specifying the Deck Title
• Omitting Fields from Cards in Generated Deck Templates
• POST or GET as Submit Method for Details Event Handlers
• No Actions Generated for Functions with Implement No
• Object Names and Labels of Actions
• Determine HTML Field Labels
• Field Alignment
• Initializing Input Fields from WML Variables
• Limited Size of WML Decks

Specifying the Deck Title

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.

Omitting Fields from Cards in Generated Deck Templates

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:

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.

POST or GET as Submit Method for Details Event Handlers

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:

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).

No Actions Generated for Functions with Implement No

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.

Object Names and Labels of Actions

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.

Determine HTML Field Labels

The Deck Template Generator pattern in Websydian determines the WML field label in the following order of priority:

1. Left label if defined
2. Top label if defined
3. Field name.  If the field has a FLD name NME triple defined, the name object is used as the WML field label.

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:

1. The large property of the label if defined
2. The name triple of the label if defined
3. The name of the label object

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.

Field Alignment

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.

Initializing Input Fields from WML Variables

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.

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.

Limited Size of WML Decks

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.