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

Re: Reset and insert actions

From: Aaron Reed <aaronr@us.ibm.com>
Date: Wed, 25 Oct 2006 14:26:24 -0500
To: www-forms@w3.org
Message-ID: <ehodrf$lmr$1@sea.gmane.org>

Only if the instance values set as a result of handling 
xforms-value-changed or directly through @calculate MIP.  If the values 
in the non-reset instance are set as the result of a due to handling a 
DOMActivate event or a custom event, then a rebuild wouldn't help since 
the dependency isn't maintained in the MDG.

Kugelman, John wrote:
> Wouldn't this be solved by just doing a rebuild after the reset?
> 
> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
> Behalf Of Aaron Reed
> Sent: Wednesday, October 25, 2006 2:37 PM
> To: www-forms@w3.org
> Subject: Re: Reset and insert actions
> 
> 
> John Boyer wrote:
>> Hi Leigh and Aaron,
>>
>  >...
>> Finally, in Aaron's case it is hard to imagine how the new feature
> could 
>> put the model in a state unachievable by use of an insert action given
> 
>> the claim that reseting the instance to some initial state is indeed 
>> equivalent to having an extra instance with that initial data and then
> 
>> inserting it into the instance for which reset is desired.   It's just
> 
>> two different ways of spelling the same operation, so at least the 
>> semantics should be identical.
>>
> 
> My point is that currently, every instance that can affect each other in
> 
> a model will be reset so that they are always in sync.  However with 
> this feature a user will be able to reset one instance without resetting
> 
> another.  So, for example, you could have one instance that has a 
> shopping cart and another instance that shows a person's available 
> credit on a gift card, let's say.  If the user makes some selections and
> 
> the balance is altered to reflect those choices, it would now be 
> possible that the form author to reset the cart and the balance would 
> not be reset.  Any calculation/setvalue on the form that doesn't go 
> through the calculate MIP would have this possible exposure.
> 
> Again, this would be a problem caused by the form author and completely 
> his own doing, but an issue that would not arise with the current reset.
> 
>   That was the point I was trying to make.
> 
> --Aaron
> 
> 
> 
> 
> 
Received on Wednesday, 25 October 2006 19:29:23 GMT

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