The Dream Team

Legend
	Move this row 1 up
	Move this row 1 down
	Delete this row
	Add a new row below this row

Page definition

The pipeline calls the function prot_buildTeam in team.js. There is no naming rule for flow functions, but adding a prefix ('prot_') as a simple kind of security measure to prevent outsiders from directly calling the function. Security by obscurity you might call it.

What happens?

In prot_buildTeam a list of 'positions' is generated from the information in the Manager class and passed onto the form.

<fd:field id="position">

<fd:label>Position</fd:label>

<fd:datatype base="string"/>

<fd:selection-list dynamic="true" type="flow-jxpath" list-path="positionList" value-path="value" label-path="label"/>

<fd:on-value-changed>

<fd:javascript>

// this script can be found in team.js
updateNameWidget(event);

</fd:javascript>

</fd:on-value-changed>

</fd:field>

The widget position has a selection-list of type flow-jxpath. The other attributes define the list to use:

Internationalization

The function also shows how to build this list with localized (i.e. i18n) labels.

...
// key = key code for position
// set the label to the localized message using i18n
positionList[i + 1] = {value: key, label: new I18nMessage(key)};
...

Dependency between widgets

The section on-value-changed holds the javascript that handles the dependency. When the value of the positionlist changes, the memberId widget should get a new list of names.
The script that handles this update can be entered directly between the javascript tags, but adding a descriptive function name there and moving the function to a separate javascript file keeps the widget definition file clearer. Note the event parameter.
Remember to add the submit-on-change="true" attribute to the styling tag!

Repeater validation

This repeater also has a repeater validation section, which prevents using duplicate names. Again, the script can be entered directly in the widget definition file, but it can also be added to a function that is placed in a separate javascript file. Note: this function takes widget (the current repeater) as parameter and MUST return a boolean value (true = success).
The repeater validation function is called when the Submit button is pressed. If a validation error occurs, the first invalid row will be marked with a blue !.

Some observations

The samples provide a great set of XSL files to convert the template and styling tags of the widgets into HTML. They start with forms-samples-styling.xsl and can be found in the samples/blocks/forms/resources folders.

Note: when you use these XSL files, remember to use them as the last transformation in your pipeline, or make sure they find the appropriate tags to add some scripts to the html <head> and <body> tags. Especially without a reference to the forms-lib.js file, the on-value-changed event will not be sent to the server and therefore no script is executed.

Note: At this moment (2004/10/20) a bug exists that throws a NullPointerException when the javascript in the validation section is executed with the Rhino debugger enabled!

When everything is valid

When Submit is pressed, and all rows validate, the prot_buildTeam function takes over and hands the selected team to the Manager class for further processing. Finally the function passes flow onto the showteam pipeline.