This is the value binding.

The value binding is used to derived the data displayed by the input, and also the destination of it entry. This is typically a property of an object on the server side, specified as follows:

         {objectName.property}

All form input elements, except for buttons, can have value binding.

This is typically in the form of !.attribute. The bang operator denotes that the property is from the object bound to the enclosing form. This is the typical but not universal arrangement.

For options, checkboxGroup, and radioGroup, the binding resolves to collections. These must be delineated as follows:

{objectName.property[]}

Options would property binding, one for the value and the other for the caption. (**Move info)

NOTE: There is no specification distinction as to whether bindings are single or bi-directional. However, it is obvious some element types, like outputText, could only use single directional binding.

Static Value

Whenever there is value binding for an element in the descriptor, whatever value that is assigned to the corresponding element in the source content, would be taken as mock value. If there were no corresponding binding in the descriptor, the value in the source content would be preserved.

Bindings are specified within braces in this descriptor attribute. Static values could also be specified as string. Some element types use static entries that have special meaning. These are discussed further below.

Buttons and Command Link

Buttons and command links could have static values, of which the following are the standard: new, insert, edit, update and delete. These are core modes defined for CRUD operations; an application could define additional commands. These is not the equivalent of the "value" attribute of the HTML submit, button, etc. These are command mode values assigned to the buttons.

Messages

The standard values for the message element are: error and message. This would restrict the output to error or informational messages. The absence of value entry would imply that all messages should be displayed.

The implementation, as usual, would start with the element representation in the source content. We use the input text, here as an example.

<input type= "text" name="surname"/>

The name attribute would correspond to the id entry for the element in the descriptor. In combining the source content and the descriptor entries, the implementation transformation could be made.

The transposition for this case is as follows.

This is shown below.

  <html:text name="employeeForm" property="surname"/>

With an element enclosed by a form, the object is not necessary; the implementation code could be as shown below.

  <html:text? property="surname"/>

Buttons and Command Link

The standard commands could be used with Struts, as well as custom defined ones.

With Struts the implementation would interchangeable with specified method bindings for the button, in the event descriptor. Since Struts does not have explicit method binding implementation, it is the same indirect schemes that would be used to implement it, would be applicable to transmitting the commands to the server side.

Once common implementation is to have a hidden field with name command.  The button press would then assign a value to this field, use its on click event. Interestingly, this is one of methods use to register the method binding for a request. As such, whether this command leads to unique method, or generic method act on the command, would be a matter of implementation choice.

Messages

Struts has tags to render messages or errors, as such the value specified would determine which to use. For more on messages, read the message entry in the elements table, in the overview section.