Re: Alert MIP Proposal

I reviewed the above and I think that the ability to put what LHHA
(Label-Hint-Help-Alert) closer to the data is reasonable.

One thing that comes to mind is that this should also support HTML (host
language) LHHA, as we do when using elements in the view (via UI Content).
In this case, we should probably allow for a nested element.

UI Content also allows `<output>`. Would we allow the following for example:

    <bind
        ref="creditcard"
        type="card-number"
        constraint="is-card-number(.)"
        alert="Incorrect card number"
        hint="16 digits, spaces allowed"
        whitespace="remove">

        <label>Credit card (<i><output
value="../credit-card-type"/></i>)</label>

    </bind>

-Erik


On Wed, Oct 4, 2017 at 1:36 AM, Steven Pemberton <steven.pemberton@cwi.nl>
wrote:

> The major change from XForms 1.0 to 1.1 was a process of generalisation,
> and if I were to pick out one feature that made XForms 1.1 significantly
> better, it was the ability to construct a URL from instance data.
>
> The process of going to XForms 2.0 is one of continued generalisation.
>
> The proposal to allow alerts to be in the model raises the question: Why
> not help, hint, and label as well? These are after all also closely related
> to the data.
>
> So to seed the discussion, here are some examples:
>
>   <bind ref="a" label="First number" type="integer" alert="Must be an
> integer"/>
>
>   <bind ref="b" label="Divisor" constraint=". ne 0" alert="May not be
> zero"/>
>
>   <bind ref="c" label="Percentage" type="integer" alert="Must be integer">
>       <bind constraint=". ge 0 and . le 100" alert="Must be between 0 and
> 100"/>
>   </bind>
>
>   <bind ref="d" label="{instance('m')/divisor}">
>       <bind type="integer"      alert="{instance('m')/integer}"/>
>       <bind constraint=". ne 0" alert="{instance('m')/zero}"/>
>   </bind>
>
>   <bind ref="energy">
>       <label>E = MC<h:sup>2</h:sup></label>
>   </bind>
>
>   <bind ref="birth" label="Year of birth" type="integer">
>       <bind constraint=". ge 1900" alert="Year must be after 1900"/>
>       <bind constraint=". le ../thisyear" alert="Year can be at most
> {../thisyear}"/>
>   </bind>
>
>   <bind ref="death" label="Year of death" type="integer">
>       <bind constraint=". ge 1900"        alert="Year must be after 1900"/>
>       <bind constraint=". le ../thisyear" alert="Year can be at most
> {../thisyear}"/>
>       <bind constraint=". ge ../birth"    alert="Year of death must be
> after year of birth ({../birth})"/>
>   </bind>
>
>   <bind id="age" ref="age" label="Age at death" type="integer"
> calculate="../death-../birth">
>       <bind constraint=". ge 0"   alert="Age must be greater than or equal
> to zero"/>
>       <bind constraint=". lt 130" alert="No one has ever lived to be that
> age!"/>
>   </bind>
>
>   <bind ref="creditcard" type="card-number" label="Credit card"
> constraint="is-card-number(.)"
>       alert="Incorrect card number" hint="16 digits, spaces allowed"
> whitespace="remove"/>
>
>   <bind ref="expires" label="Expires" constraint="matches(.,
> '^dd/0d|dd/1[12]$')" alert="Format must be YY/MM">
>     <hint appearance="minimal">YY/MM</hint>
>   </bind>
>
> These are all optional (the onld method of putting them on the control
> still works), but has the advantage of keeping the pieces of information
> about the data together in one place.
>
> How do we deal with controls that have required labels?
>
> 1. Make <label> optional on controls that have bindings to values with
> bound labels.
> 2. If a control has a label binding and a label, the control label takes
> precedence, allowing override in specific cases.
>
>   <bind ref="/login/password"  label="Password"
>         help="Have you forgotten your password? Simply call 1-900-555-1212
> and have a major credit card handy."/>
>
>   <secret ref="/login/password"/>
>
>   <input ref="creditcard"/>
>   <input ref="expires"/>
>
>   <input bind="age"/>
>
>   Age at death was: <output bind="age" label=""/>
>
> Steven
>
>