W3C home > Mailing lists > Public > public-forms@w3.org > January 2009

Problems with Submission Module

From: Ulrich Nicolas Lissť <unl@dreamlab.net>
Date: Wed, 28 Jan 2009 15:35:27 +0100
Message-Id: <3A5F9C03-6F04-460A-89D1-FE1A7241DE41@dreamlab.net>
To: Forms WG <public-forms@w3.org>

Dear Group,

when making first humble steps to extract a Submission Module from the  
Spec I encountered following problems:

* Inter-module dependencies

The Submission module can be regarded as kind of Declarative XHR.  
Binding Attributes, Relevance Pruning and Validation are inherently  
XForms-specific and should therefore be optional so that the  
Submission Module becomes useful on its own.

First, the Submission Module should reference the Binding Attributes  
Module to be able to indicate which data to submit. It seems easy to  
reference the Binding Attributes Module (spec text could read "The  
Submission Module uses the Binding Attributes Module to indicate which  
data to submit." or something similar). However, how could it (should  
it?) work without Binding Attributes?

Next, the Submission Module should interact with other modules  
providing Relevance Pruning and Validation. We decided to try to use  
events for this kind of loose module coupling, but this poses other  
problems (see below). So in case it turns out that events are not  
suitable for module integration we need to think about other mechanisms.

Side note: I've lost track which module will provide deferred updates.  
The Driver Module? How would this be invoked? Another event?

* Additional Events

When factoring Relevance Pruning and Validation out of xforms-submit  
processing the easy part is to define new events, e.g. xforms-submit- 
filter and xforms-submit-validate. But how are these events supposed  
to work? Actually, they would serve as a method interface with  
parameters and a return value. That's fine because we can use event  
properties for that.

The xforms-submit-filter event would have a property indicating the  
data to process (essentially the binding expression). However, it  
would need another property as return value (or another event like  
xforms-submit-filter-result?) containing the filtered data, i.e. all  
relevant instance nodes. So we have the same problem here like we have  
with xforms-submit-serialize: Do we want to transport instance data in  
events? Does it really impose performance penalties?

Furthermore, the xforms-submit-validate event would have to pick up  
those data again in order to "request" validation. And of course it  
would need some validation success indicator so that submission  
processing can stop upon validation errors.

* Life after submit

The new and useful xforms-submit-result-received event should be  
introduced which is fine except for the question whether to store the  
submission result in an event property. Additionally, the Wiki states  
"XForms driver module would define attributes ref, bind, validate,  
relevant, replace, target, instance". When the XForms Driver Module  
will introduce @replace, @target and @instance, will it also specify  
the according processing rules? While it is fine that the Driver  
Module adds value to modules doesn't this mean that processing rules  
will be scattered across modules?

Regards,
Uli.
--
Ulrich Nicolas Lissť
Received on Wednesday, 28 January 2009 14:36:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:50 UTC