- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 6 Feb 2007 17:22:06 -0800
- To: mark.birbeck@x-port.net
- Cc: "Clark, John" <CLARKJ2@ccf.org>, "Klotz, Leigh" <Leigh.Klotz@xerox.com>, Nick_Van_den_Bleeken@inventivedesigners.com, www-forms@w3.org, www-forms-request@w3.org
- Message-ID: <OF51333F1E.E54A7B58-ON8825727B.000232EE-8825727B.00078578@ca.ibm.com>
Hi Mark,
While I have also been concerned with the question you attributed to me
below about what happens if one deletes the context node, the inspiration
for E31 was more directly due to the concern that event handlers such as
for xforms-invalid should simply not be executed in non-relevant UI
content (otherwise, they aren't really irrelevant). The extension to that
was non-selected cases of a switch.
Also, to be clear, the server-side processor optimization Mark described
is made possible by this erratum, but we wrote it in such a way that
client-side implementations are not compelled to physically remove the
non-relevant content from the main running DOM while it is non-relevant.
But coming back to E31, I believe it has not quite been worded in a way
that addresses the concern about deleting the context node. However, I
believe it is reasonable to assert that XPath expressions which cannot be
evaluated due to the absence of a context node should simply behave as if
an empty result was obtained. So, nodeset and ref would behave as if an
empty nodeset were obtained, and the value attribute of an output would
receive an empty string,
So, in Mark's example (which I pasted below for clarity), I don't think
the second message action would include the text "I should appear in the
message window." But I do think it's reasonable that the message action
occurs.
<xf:model functions="fp:HTMLserialise" id="m">
<xf:instance id="i">
<i xmlns=""><marker/></i>
</xf:instance>
<xf:instance id="j">
<j xmlns=""><foo>I should appear in the message window.</foo></j>
</xf:instance>
</xf:model>
<xf:group ref="instance('i')/marker">
<xf:trigger>
<xf:label>Destroy <code>instance('i')/marker</code>
and<br/>display
contents of <code>instance('j')/foo</code></xf:label>
<xf:action ev:event="DOMActivate">
<xf:message level="modal"
><code>foo</code>:
<xf:output value="instance('j')/foo"/></xf:message>
<xf:delete context="instance('i')/marker" nodeset="."/>
<xf:rebuild/>
<xf:refresh/>
<xf:message level="modal"
><code>foo</code>:
<xf:output value="instance('j')/foo"/></xf:message>
</xf:action>
</xf:trigger>
</xf:group>
As you can see from this example from Mark, the trigger shows a message,
then deletes the node referenced by the group. The refresh makes the
group non-relevant, which disconnects its event handlers. That's
different than disabling actions within the content, so I believe the
action sequence continues after the refresh. But the final message action
would seeming show just "foo:" because the context node for evaluating the
output @value is gone.
However, had the refresh not occured, I would say that the context node
was detached from instance data, but it still exists because the group
still has a reference to it until the next refresh. In that case, I would
expect the second message to match the first one since the @value
attribute uses absolute referencing, so a context node need only exist in
this case.
Unfortunately, this problem is more complicated than the above example
when refresh is explicitly called. Suppose the trigger is within a
repeat, and suppose the delete operation removes the context node of the
trigger. Then, call refresh. One would think that the action sequence
being executed is destroyed by the refresh of the repeat. So, it's an
open question whether any actions after the refresh should occur. But you
can maybe see how E31 got the higher priority because the form author is
not actively shooting at his own foot, so to speak.
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com http://www.ibm.com/software/
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
"Mark Birbeck" <mark.birbeck@x-port.net>
Sent by: www-forms-request@w3.org
02/06/2007 11:06 AM
Please respond to
mark.birbeck@x-port.net
To
"Klotz, Leigh" <Leigh.Klotz@xerox.com>
cc
Nick_Van_den_Bleeken@inventivedesigners.com, "Clark, John"
<CLARKJ2@ccf.org>, www-forms@w3.org, www-forms-request@w3.org
Subject
Re: Event handlers defined in irrelevant form blocks
Nick is right. This was intended to clarify whether relevance could be
implemented using something like "display: none;" in CSS (which leaves
the controls intact, but just hides them), or whether the non-relevant
nodes were in effect 'removed' from the document, and did not
participate in any way.
The two are very different, because if you attach to a control an
'xforms-value-changed' handler that simply adds 1 to a node, and then
ensure that the control becomes non-relevant, you will get different
results from the 'add 1' part, depending on how relevance is
implemented.
Anyway, the latter technique is much more efficient on very large
forms, and is particularly useful when implementing a server-based
XForms processor, where you can save bandwidth and processing time by
not delivering non-relevant controls to the UI.
Having said all of that... :) in John's original question the action
that was failing concerned a handler that was running in the context
of a node that was *deleted* in a prior processing stop in the same
handler. This meant that the second action failed because its
evaluation context had just been obliterated! The thread of discussion
is here:
<http://www.formsplayer.com/node/698>
Regards,
Mark
On 06/02/07, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:
>
> Oops!
>
> -----Original Message-----
> From: Nick_Van_den_Bleeken@inventivedesigners.com
> [mailto:Nick_Van_den_Bleeken@inventivedesigners.com]
> Sent: Tuesday, February 06, 2007 12:00 AM
> To: Klotz, Leigh
> Cc: Clark, John; www-forms@w3.org; www-forms-request@w3.org
> Subject: RE: Event handlers defined in irrelevant form blocks
>
> All,
>
> Didn't this recently change by issuing erratum 31.2 Rigorously Define
> Non-relevant Form Control
> (http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E31b)? It
> explicitly states that "A critical part of this erratum is that XForms
> action handlers for events on the form control are disabled when the
> control is non-relevant" this the of course repeated in the 'Changed
> specification wording' section "When a form control becomes
> non-relevant,
> it must receive event xforms-disabled and then the XForms action
> handlers
> that are listening for events on the non-relevant form control must be
> disabled." Or am I reading this incorrectly?
>
> Regards,
>
> Nick Van den Bleeken - Research & Development
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivedesigners.com
>
> www-forms-request@w3.org wrote on 02/05/2007 07:00:37 PM:
>
> >
> > John,
> > No, relevance has no effect on action handlers. Relevance does affect
> > submission and validation (modulo the submission/@relevant attribute).
> > There are also some events that are sent to in response to relevance
> or
> > instance node appearance/disappearance (xforms-enabled,
> xforms-disabled)
> > so you will see some effect there. (Does anybody think differently
> > here?)
> >
> > Although it doesn't have to be the case, most XForms 1.0 integrations
> > with XHTML use relevance to control the :enable and :disabled CSS
> > properties.
> >
> > If you need to control actions, take a look at the new conditional
> > attributes on actions in XForms 1.1.
> > Leigh.
> >
> > -----Original Message-----
> > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
> > Behalf Of Clark, John
> > Sent: Monday, February 05, 2007 7:24 AM
> > To: www-forms@w3.org
> > Subject: Event handlers defined in irrelevant form blocks
> >
> >
> > If you define an event handler somewhere in a form element, and that
> > form element becomes irrelevant, does that disable (or in any other
> way
> > change) the event handler somehow? Does it matter whether or not the
> > observer for the event handler is a descendant of the irrelevant form
> > element?
> >
> > Take care,
> >
> > John L. Clark | Systems Analyst
> > | Cardio-Thoracic Surgery Research
> > Cleveland Clinic | 9500 Euclid Ave. | Cleveland, OH 44195
> > | (216) 445-6011
> >
> > ===================================
> >
>
>
> --------------------------------------------------
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
>
>
--
Mark Birbeck
CEO
x-port.net Ltd.
e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/
Download our XForms processor from
http://www.formsPlayer.com/
Received on Wednesday, 7 February 2007 01:22:20 UTC