- From: Ulrich Nicolas Lissé <unl@dreamlab.net>
- Date: Wed, 28 Jan 2009 15:35:27 +0100
- 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