How to respond to 'xforms-out-of-range'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to respond to 'xforms-out-of-range'

Ronald van Kuijk-4
@,

I've been reading the spec with regard to the xforms-out-of-range event and cannot get a clear picture on how to respond to this event.

In the spec it says nothing about a select control receiving this event being either still valid or invalid. An empty string  (e.g. the default) can be valid according to the xsd that is behind it and even according to the constraint. So the control is then valid but out of range, correct? Personally I'd say the visual response to this should be to render the control as being invalid, so the out-of-range taking precedence.

Theoretically it could also be the other way around. The control being invalid according to e.g. a constraint, but being in range. Since you (hope to) have other choices in the select, you could probably make it valid by selecting another item, so in this case the invalidness of the control takes precedence.

This is just how I would interpret things, so if someone from the wg could confirm this or describe the correct behaviour, that would be great.

Cheers,

Ronald
Reply | Threaded
Open this post in threaded view
|

Re: How to respond to 'xforms-out-of-range'

John Boyer

Hi Ronald,

The empty string is not out of range for select and select1 controls (see esp. the notes in Section 8.1.1 for select1 controls).

Yes, we agree that a select or select1 can be in range but invalid.  The in range/out of range eventing is about the UI control's ability to properly show the bound data value, notwithstanding whether the model regards it as valid or invalid.

Best regards,
John Boyer
Reply | Threaded
Open this post in threaded view
|

Re: How to respond to 'xforms-out-of-range'

Ronald van Kuijk-4
In reply to this post by Ronald van Kuijk-4
Hi John,

Thanks for replying and thanks to the WG for putting it on the list for todays meeting. It was not that obvious was it?

>
> The empty string is not out of range for select and select1 controls (see
> esp. the notes in Section 8.1.1 for select1 controls).
>

I missed this, thanks for pointing it out, but the empty string was just an example. It could  as well be a non-empty one that is in the instance from somewhere else.
 
> Yes, we agree that a select or select1 can be in range but invalid.  The
> in range/out of range eventing is about the UI control's ability to
> properly show the bound data value, notwithstanding whether the model
> regards it as valid or invalid.
>

In range but invalid is not the real problem. A kind of html like select will show the corresponding label then. The other way around is harder. 'Properly showing the bound data value' is to me (a non-native English speaker) also 'explicit'. Does it mean the control should (must?) in some way or another show the value that cannot be shown in the select itself? E.g. a dymamic, non specified (xforms) alert that is probably not customizable by the form developer? Or e.g. Dynamically adding it to the nodeset/items for the select and doing some magic things, or....? It feels like this is against the phylosophy of XForms of declaritively defining behaviour.

Cheers,

Ronald

Reply | Threaded
Open this post in threaded view
|

Re: How to respond to 'xforms-out-of-range'

John Boyer

Hi Ronald,

Please see inline.

Thanks,
John Boyer


From: "Ronald van Kuijk" <[hidden email]>
To: John Boyer/CanWest/IBM@IBMCA, [hidden email]
Date: 09/08/2010 10:22 AM
Subject: Re: How to respond to 'xforms-out-of-range'





Hi John,

Thanks for replying and thanks to the WG for putting it on the list for todays meeting. It was not that obvious was it?

JB> I thought it was; why do you say it wasn't?

>
> The empty string is not out of range for select and select1 controls (see
> esp. the notes in Section 8.1.1 for select1 controls).
>

I missed this, thanks for pointing it out, but the empty string was just an example. It could  as well be a non-empty one that is in the instance from somewhere else.

JB> Yes but if the value is non-empty and doesn't match one of the items, then it's out of range.  The language of the note specifically says that, so when you say that empty string is just an example, I'm trying to figure out what other example you want me to consider that actually is *not* covered by the spec.
 
> Yes, we agree that a select or select1 can be in range but invalid.  The
> in range/out of range eventing is about the UI control's ability to
> properly show the bound data value, notwithstanding whether the model
> regards it as valid or invalid.
>

In range but invalid is not the real problem. A kind of html like select will show the corresponding label then. The other way around is harder. 'Properly showing the bound data value' is to me (a non-native English speaker) also 'explicit'. Does it mean the control should (must?) in some way or another show the value that cannot be shown in the select itself? E.g. a dymamic, non specified (xforms) alert that is probably not customizable by the form developer? Or e.g. Dynamically adding it to the nodeset/items for the select and doing some magic things, or....? It feels like this is against the phylosophy of XForms of declaritively defining behaviour.

JB> Generally, if it's not in the spec, then there is no expected interoperability with respect to how it is handled.  For example, one tends to create run-time/UI objects that are associated with each of the item elements (or each item generated by an itemset); I definitely would not expect more run-time/UI objects to be created to represent spurious data values that don't match any of the items in the select/select1.  Nothing in the spec suggests that this should happen, so why should this happen?

JB> In the case of a select1 or select, is that the run-time/UI object(s) associated with item(s) whose value(s) is(are) matched to the bound data node value are regarded as selected, and the remainder of the item(s) are regarded as unselected.  So, your select or select1 may show zero selected items because the string is empty or because the string is non-empty but none of the items match the non-empty data node content.  The xforms-out-of-range event is issued in the latter case so that it can be distinguished from the former.

JB> Finally, note that in XHTML+XForms, there is the possibility that the CSS pseudo-classes mentioned in Appendix G.1 will be available, where the :out-of-range and :in-range pseudo-classes are the ones pertinent to this discussion.  But obviously the availability of that mechanism is up to the implementation that integrates XForms with a host language such as (X)HTML.

Cheers,

Ronald