Re: regarding Action 2007-05-23.2: Value changes upon instance replacement

Erik Bruchez wrote:
> 
> Joern & all,
> 
> We tackled some of this in today's call, but I wanted for the record
> to comment a bit on the solution below for the record.
> 
> It is my understanding, based on our discussion in the call, that the
> proposed solution comes down to marking every node in the instance as
> requiring dispathing xforms-value-changed upon instance replacement.
> 
> If that's the case, and if we were to actually require this, I think
> we should make it much more explicit and amend the wording in the
> submission to state this.
> 
> But now about this solution in general:
> 
> What Joern describes is, by the way, the solution we implement in Orbeon
> Forms.
> 
> However, even though we do implement it this way, we do not think that
> it is a great solution. We implemented it because like Joern, we
> couldn't find a really better solution given the tight requirements and
> the way refresh is currently specified.
> 
> Consider the following control:
> 
>   <xforms:input ref="some/element">
> 
> and then an instance like this:
> 
>   <instance>
>     <some>
>       <element>Joe</element>
>     </some>
>   </instance>
> 
> I can change my instance almost completely to:
> 
>   <foo>
>     <bar/>
>     <some>
>       <other/>
>     </some>
>     <some>
>       <stuff/>
>       <element>Joe</element>
>     </some>
>     <yet-some>
>       <element>
>         <with-stuff/>
>       </element
>     </yet-some>
>   </foo>
> 
> Before instance replacement, my input is bound to the unique "element"
> node. Then after replacement, upon refresh, the input is newly bound
> to an "element" node. However, the structure of the instance has
> changed quite a bit. In this case, I have decided not to change string
> value of the element, so in both cases the input control will show
> "Joe".
> 
> The solution to mark all nodes works, but it is costly and
> non-optimal. It is also intuitively incorrect in that control whose
> value has not changed will all dispatch xforms-value-changed.
> 
> We can argue, as John did, that the *element node* has changed, but
> remember the name of the event is *value changed*. XForms authors,
> including myself, really think that "value changed" should say what
> its name implies, i.e. fire when the control value changes.
> 
> So the bottom line is that I am not very happy with this solution. I
> think we could do one of four things:

i completely agree with you both in analysis and your feelings about the 
'solution'. Actually i only proposed it in this form in order to not get 
into too much trouble with current event system.
> 
> 1. Wait for XForms 1.2.
> 
> 2. Use this solution temporarily, but then it's harder to "undo" it in
>    XForms 1.2.
Agree again. Might be better to really address the problem now than to 
bend the architecture into place
> 
> 3. Introduce the xforms-control-bound event, mark all nodes for
>    dispatching it, then dispatch MIP events. What we gain from this is
>    that at least we don't incorrectly use the words "value changed".
But how would that look like? After an instance replace do we fire a 
xforms-refresh or not? So we would have effectively two kinds of 
xforms-refreshes - one firing xforms-value-changed events and one firing 
xforms-control-bound events?

Though i thought about an event myself i not at all sure that it makes 
sense to add a 'xforms-control-bound' event. Where are the use cases 
here from an authors perspective? If the event only happens after 
instance replacement couldn't the author not simply use 
xforms-submit-done then as a hook?

Joern

> 
> 4. Do more work and implement UI events correctly, that is in a way
>    which is less confusing for form authors and which would be
>    hopefully 100% reliable, i.e. a control would dispatch
>    xforms-value-changed if and only if its value has changed since last
>    refresh.


> 
> -Erik
> 
>  > after investigation i found that most of the issue has already been
>  > answered by John Boyer in:
>  > http://lists.w3.org/Archives/Public/public-forms/2007May/0081.html
>  >
>  > I fully agree with his John's position. His arguments which i summarize
>  > here shortly for reference:
>  >
>  > - MIP events are fired during refresh. Refresh does not happen during
>  > init as controls are *created* (not updated/refreshed) and get to their
>  > state directly without the need for the MIP events. So init and instance
>  > replacement are two different cases which should be kept separate (my
>  > conclusion)
>  >
>  > - after a successful instance replacement a refresh (which in
>  > turn will trigger the MIP events) will happen as stated under "11.2 The
>  > xforms-submit Event":
>  >
>  > "Once the XML instance data has been successfully replaced, the rebuild,
>  > recalculate, revalidate and refresh operations are performed on the
>  > model, without dispatching events to invoke those four operations. "
>  >
>  > In conseguence the problem boils down to the description of the
>  > xforms-refresh Event as John already pointed out.
>  >
>  >
>  > Proposed new text:
>  >
>  > 4.3.4 The xforms-refresh Event
>  >
>  > (...)
>  > 2. A node can be changed by confirmed user input to a form control, by
>  > xforms-recalculate (section 4.3.6), by the setvalue (section 10.1.9)
>  > action or by instance replacement (section 11.18). If an instance data
>  > node was changed or has been replaced, then the node must be marked for
>  > dispatching the xforms-value-changed event.
>  >
>  > Explanation:
>  > First sentence now mentions the instance replacement as a explicit
>  > source for value changes. In the second sentence i've deleted 'the value
>  > of' - i think it's not necessary to talk about the *value* of a node
>  > here cause a change to the value is of course also a change to the node
>  > itself.
>  >
>  > Though the semantics of xforms-value-changed is not a perfect match
>  > because of the 'value' in it i do not see another easy solution without
>  > reworking other parts of the Spec or maybe even inventing a new
>  > 'xforms-instance-replaced' event.
>  >
>  > We can even argue that the value of a node has changed even in case it's
>  > an equally named node with an identical value. The node would not have
>  > the same identity and so its value as John already pointed out:
>  >
>  > "Note that this should occur whether or
>  > not the literal value has changed because the node containing the value
>  > has changed, i.e. it is a different string even if it contains the same
>  > lexical value."
>  >
>  > Joern
>

Received on Thursday, 7 June 2007 13:10:49 UTC