W3C home > Mailing lists > Public > public-forms@w3.org > October 2014

Feedback on the caseref feature

From: Erik Bruchez <erik@bruchez.org>
Date: Fri, 17 Oct 2014 11:11:47 -0700
Message-ID: <CAAc0PEUvGhEt5rNZJdpB3dSmZd=ak8H3DqZb2voZ26Q05f-eAQ@mail.gmail.com>
To: Forms WG <public-forms@w3.org>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
All,

We started implementing support for caseref [1], and here is some feedback:

1. Controls can be bound to atomic values, therefore caseref should be as well.

Currently the spec says that "The result is interpreted as a
node-sequence, and the first node is obtained". It doesn't say what
happens if no node is obtained. Instead, this should be defined in
terms of "Single Item Binding". Binding to an item is the same as
binding to a readonly node, as for controls.

2. Case selection in case of presence of child elements

We say that an error event is dispatched, but we don't say what else
must happen. I suggest we should say that the first case is selected.

3. We don't say when to dispatch the xforms-binding-error in case of a
binding error.

The spec doesn't say this, but the caseref binding must be reevaluated
during refresh. It is dangerous to dispatch events *during* the
process of updating bindings, as some controls will have their
bindings updated, and some not yet.

For MIP and change events, we say that we dispatch them during a
separate phase. We should probably say the same for a
xforms-binding-error detected when updating control bindings.

4. Whether and when to dispatch xforms-select / xforms-deselect

We generally say, when talking about switch / case, that xforms-select
/ xforms-deselect must be dispatched when the selected case changes.
But we don't say anything about these events in relation to caseref. I
suggest making it more explicit that the events must be dispatched at
the same time the other UI events are dispatched during the refresh
process.

5. We currently store the case *id* only

This is quite limiting, as ids have to be globally unique. This means
you cannot perfectly control the storage value associated with a
switch/case, and also that you cannot have, for example, 2 switches
kept in sync by binding with caseref to the same node, as that would
imply that they must have the same case ids.

I suggest, by compatibility with xf:item/xf:itemset and single
selection controls, to add the ability to select a storage value. This
should be done with a @value attribute, and possibly, for consistency,
with a nested xf:value attribute. They would behave the same as
xf:item/xf:itemset. Example:

<xf:switch caseref="my-case">
    <xf:case id="my-case-1" value="'literal-value1'"/>
    <xf:case id="my-case-2" value="'literal-value2'"/>
    <xf:case id="my-case-3" value="dynamic-value-3"/>
</xf:switch>

-Erik

[1] https://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_switch_Element
Received on Friday, 17 October 2014 18:12:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:10 UTC