RE: Reset and insert actions

Sounds like that's the form author's problem to deal with. They can
follow up the reset with whatever extra cleanup work is needed.

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Aaron Reed
Sent: Wednesday, October 25, 2006 3:26 PM
To: www-forms@w3.org
Subject: Re: Reset and insert actions


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 21:28:51 UTC