W3C home > Mailing lists > Public > www-forms@w3.org > August 2006

RE: send can violate bind/@constraint

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Wed, 16 Aug 2006 10:38:22 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF4021EB3A2@usa7061ms01.na.xerox.net>
To: "John Boyer" <boyerj@ca.ibm.com>, Ulrich NicolasLissť <u.n.l@gmx.net>
Cc: "Erik Bruchez" <ebruchez@orbeon.com>, <www-forms@w3.org>
Note that it's not just xf:send; xf:dispatch would have the same effect.
Leigh.

________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of John Boyer
Sent: Wednesday, August 16, 2006 7:59 AM
To: Ulrich NicolasLissť
Cc: Erik Bruchez; www-forms@w3.org; www-forms-request@w3.org
Subject: Re: send can violate bind/@constraint



Yes.  We could/should improve the behavior of send so that it runs the actions suggested by the deferred update flags before dispatching xforms-submit. 

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms 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





Ulrich Nicolas Lissť <u.n.l@gmx.net> 
Sent by: www-forms-request@w3.org 

08/15/2006 02:46 PM 

To
Erik Bruchez <ebruchez@orbeon.com> 
cc
www-forms@w3.org 
Subject
Re: send can violate bind/@constraint

	





Hi *,

I share your interpretation. This issue is an unintended consequence of 
deferred action behaviour. A simple workaround would be to insert a 
<xf:recalculate/> before <xf:send/>. However, this is not obvious to 
form authors and there should be at least a hint in the spec.

I thought about forcing xforms-submit processing to perform a 
calculation prior to validation. But this might easliy lead to 
inconsistencies: Validation can operate on the relevant subset of nodes 
selected by submit without side-effects, but this doesn't hold for 
calculation.

Any ideas ?

Uli.

Erik Bruchez wrote:
> 
> Leigh, Aaron:
> 
> I read the spec the same way, and unfortunately it is true that this 
> behavior breaks the reasonable assumption that submission will only 
> submit an instance that has passed validation AND the "required and not 
> empty" rule (unless you use XForms 1.1's new @validate or @required 
> attributes to disable those constraints).
> 
> I hope that this is an unintended consequence of the spec and that 
> somehow we can fix it in an errata.
> 
> -Erik
> 
> Aaron Reed wrote:
>>
>>
>>> I recently encountered two different XForms processors that do this.
>>> While I think the behavior is incorrect, it may be that it is emergent
>>> from the events described in the spec.
>>>
>>> Leigh.
>>
>> As I work on a processor that does not catch the constaint violation 
>> that Leigh mentions, I can give you my interpretation of the spec.  In 
>> xforms-recalculate 
>> (http://www.w3.org/TR/xforms/index-all.html#evt-recalculate), it 
>> mentions that this is where the model item property evaluations occur. 
>> I see not other place in the spec that mentions MIP evaluation.  When 
>> xforms-recalculate happens, we store the resulting node states in the 
>> MDG.  This is what we reference when a submission request occurs.
>>
>> In Leigh's example, during the xf:action, a xf:setvalue happens. 
>> However, all of our remembered constraint, relevancy, etc. nodestates 
>> are for the previous node value until recalculate happens.  Since 
>> recalculation is deferred in Leigh's example, this won't happen until 
>> after the xf:send happens.
>>
>> I believe that we are working in accordance to the spec.  If we are 
>> not, please let us know which MIP evaluations should happen that we 
>> are missing and when they should happen.  I can kindof see in the spec 
>> where  possibly relevancy and constraint should be evaluated during 
>> submission, but that also doesn't make sense to me since I definitely 
>> don't see where @calculate would be processed and constraint could 
>> easily be dependent on the result from an @calculate which didn't run.
>>
>> Have a great weekend all,
>> --Aaron
> 


-- 
Ulrich Nicolas Lissť
Received on Wednesday, 16 August 2006 17:38:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT