- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Tue, 19 Aug 2008 16:18:31 -0700
- To: www-forms@w3.org
Joern,
I guess we should discuss this during the next telecon.
In general, regarding the actions that halt processing, I agree that
in some cases at least we should allow the form author to prevent the
execution of the default action (i.e. prevent stopping the processing).
This in particular applies to the evaluation of XPath expressions.
Expressions in actions, in particular, should be recoverable. FWIW
back in the days I sent more details about the confusion of xforms-
compute-exception and xforms-binding-exception [1].
-Erik
[1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0059.html
On Aug 13, 2008, at 3:45 PM, Joern Turner wrote:
>
> Please consider the following snippet:
>
> <xf:model id="model">
> <xf:setvalue ev:event="xforms-link-exception"
> ref="instance('test')/foo" value="'bar'"/>
> <xf:instance id="test" xmlns="">
> <data>
> <foo></foo>
> </data>
> </xf:instance>
> <xf:instance id="instance" xmlns=""
> src="nonExistingResource.xml"/>
> </xf:model>
>
> Under 3.3.2 i read:
> "If the initial instance data is given by a link (from src or
> resource), then the instance data is formed by creating an XPath data
> model of the linked resource. If the link cannot be traversed, then
> processing halts after dispatching an xforms-link-exception with a
> resource-uri of the link that failed."
>
> As processing halts after the xforms-link-exception is the setvalue
> action executed (resulting in instance 'test' having a node foo with
> value 'bar') or not? As processing is stopped anyway you can argue
> that this makes no difference as you can't do anything with that value
> anyway. Do i miss something?
>
> What would be the correct (conformant) behavior for an
> implementation here?
>
> Second question:
> isn't there a good reason why the above maybe shouldn't work without
> interrupting processing (non-fatal exception) as it is the case with a
> xforms-submit-error?
>
> Imagine a form calling a remote service with a @src URI - but it
> cannot always foreseen if the service is always available. If the
> above would work without stopping the 'test' instance could give
> explanations to the user about the problem and maybe continue
> processing on an alternative branch.
>
> The whole thing becomes even a bit trickier if you put it like this:
> <xf:model id="model">
> <xf:setvalue ev:event="xforms-link-exception"
> ref="instance('test')/foo" value="'bar'"/>
>
> <xf:instance id="instance" xmlns=""
> src="nonExistingResource.xml"/>
> <xf:instance id="test" xmlns="">
> <data>
> <foo></foo>
> </data>
> </xf:instance>
> </xf:model>
>
> If the link-exception is dispatched right after initialization of
> first instance failed there would be no way to execute the setvalue
> action as the target instance have not yet been created.
>
> On the other hand from an author's point of view i can imagine the
> following being desirable:
> <xf:model id="model">
> <xf:instance id="instance" xmlns=""
> src="URI_of_firstInsecureServiceProvider-1"/>
> <xf:instance id="test"
> src="URI_of_firstInsecureServiceProvider-2" xmlns=""/>
> </xf:model>
> If the link-exception wouldn't be fatal you'd be able to implement a
> fall-through this simple.
>
> To be most valuable the dispatching of the link-exception should be
> deferred until all instances have initialized (or tried to do so).
> Then a meaningful reaction for the user would be possible:
> <xf:model id="model">
> <xf:setvalue ev:event="xforms-link-exception"
> ref="instance('test')/foo" value="concat('Service at:' +
> 'event("resource-uri")' + "failed to respond"/>
>
> <xf:instance id="instance" xmlns=""
> src="nonExistingResource.xml"/>
> <xf:instance id="test" xmlns="">
> <data>
> <foo></foo>
> </data>
> </xf:instance>
> </xf:model>
>
> Thanks,
>
> Joern
>
>
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Tuesday, 19 August 2008 23:19:13 UTC