WSubordinateControl action: setValue

[ghost]

Offline enhancement request:

• allow WSubordinateControl to set the value of another control.

[JohnMcGuinness]

I am working on a project where this cold certainly be used. Over the life of my project (3-4 years) I have had a few situations where I've had to use AJAX to set a value where otherwise I could have used Subordinate. @jonathanaustin @ricksbrown @marksreeves I would vote this up if GitHub allowed me to.

[ghost]

OK, let's bump the priority.

[ricksbrown]

Bump.

After a long talk about how to improve subordinate this came up again as a prime candidate.

[ricksbrown]

A few notes:

• this probably only needs to run client side
• we could/should allow arbitrary subordinate actions to be taken instead of only the predefined ones. It is trivial to add client side subordinate actions but there is no easy way to target those actions from the server side API.
• We already have client side select, unselect and toggleselect these are similar to setValue and probably should be exposed too.

In its most basic form it would be this easy:

Action.register("setValue", function(element) {
            element.value = "some value you somehow know you want?";
});

But, things to consider:

• "setValue" on a radio button or other selectable / checkable (should probably check an item that "matches" the value.
• "setValue" is called on a disabled or readonly field (should ignore)
• Ensure observers/listeners are notified (fire the change event)
• Is internationalization an issue?
• "clearValue" required? "resetValue" required?

[ghost]

Some thoughts:

• I am unconvinced the ability to set arbitrary String values is useful. An application that can arbitrarily set an unconstrained string value in the client based on user input elsewhere smells like magic to me (and magic always leads to trouble). Take the common use case of "my postal address is the same as my home address": in this case it would be more appropriate to remove the postal address fields than auto-populate them.

  Setting constrained values though - selection in a list, dates, possibly numbers - these make more sense.

• For setting date and number values we may want a reference element which is not necessarily the subordinate trigger. Example: when selecting the checkbox "return trip", enable/show WDateField returnDate and set its value to the value of WDateField outwardDate [+ N days]. In this example we will probably also want outwardDate to be another trigger to set the returnDate value so subsequent changes to outwardDate update returnDate.

  Then we have constraints on setValue so we could, in the example above, allow outwardDate to update returnDate only if returnDate is empty or earlier than the new value of outwardDate. Not so easy now is it? The only sensible way to do this is to allow subordinate actions to be defined in JavaScript rather than trying to abstract them into a Java API.

• i18n may be a bit irrelevant for setting value in a constrained Input. Setting value in a selectable list control (such as WRadioButtonSelect, WCheckBoxSelect, WDropdown) based on the option value or the option's visible string should be transparent as the value ought not change and the visible string should be internationalised anyway.

  Setting a date in a WDateField should use the HTML5 date format - leave display of locale-aware dates to the user-agent and our attempt to force internationalise-able unambiguous dates in our fill. Numbers are pretty much numbers and once again using input type number should internationalise if required (decimal separator for example).

• Clearing a value: is this not the same as setting it to empty where empty could be null, an empty String or the value of a null option?

  Actually, after typing and thinking I rather like having an explicit clearValue in the Java API - it removes all those different definitions of empty - especially handy for selection components which may or may nor support null selection.

• Reset is an interesting issue and one we have never really taken on board (for the usual historical reasons). Moving away from the old transactional forms of IE6 based intranet applications now allows us more flexibility in keeping application history and resetting form state, but resetting individual controls should be reasonably easy.

  Reset would have to be subtle enough to reset the current view in most cases; but what if the reset control was inside a cognitive container (such as a tab or even a fieldset with a visible border) - perhaps then "reset" could be taken to mean "reset this container". So a reset action would need an optional resettable container which if not targeted would reset the current view.

  If we are going to have a Subordinate Action of reset then maybe we should also revisit WResetButton?