Re: multiple instance/model submission

Thanks Victor,
	you are of course correct, but it wouldnt be too tough for the spec to 
allow the wrapping of the submissions with some arbitrary element, or to 
use the model element name as a default.
Your use case and solution are fine as long as you are only talking 
about responding to one form or one person.
In my case I have a complex and arbitrary workflow, and multiple 
different xforms acting as the UI depending on the user and the flow.
so even in a relatively simple case for example I will have:
user A submits data.
User B is alerted (via email or sms) that there is something they need 
to deal with.
User B logs on and is presented with a different form with options to 
acept/reject with message. - She Rejects with message.
User A: is alerted (via email/sms etc)
User A: logs on and views the existing data (modifiable by them) and the 
message for why it was rejected. They resubmit - possibly with a new 
message of their own.
User B: is alerted, logs on and this time accepts. The data is then to 
be emailed to 0-X people + saved to a central store. The flow messaging 
should not be stored - but in this case will be kept by the jbpm log 
anyway which is perfect in this case.

This is a pretty standard and somewhat trivial case - imagine what it 
would be like when it gets complex with groups of authorisers, flows 
based on flows, and more ancillary data than just messages.

It would be nice to have the choice to keep my data separate from my 
working stuff. The xform itself lets me do this, but it wont let me 
submit it all to the server so I can keep it together easily.

It seems that probably my only real option at the moment is to add all 
this working stuff to my data instance, make sure ALL my forms can cope 
with all the variations in the potential schema, and then delete it all 
when I need to store the data I actually want.

Incidentally, in my case because I have left the definitions of who 
should be emailed the final data up to the xform itself, it does make 
for some weird thought processes to integrate with the workflow engine 
though. Xforms email submissions etc are very handy, but unless its a 
simple relatively standalone form, I'm not sure they should really be 
used as in my case. It just feels weird.

Thanks for your input Victor.
Regards
Jason.



Victor Bolshov wrote:

> I am not that much a specialist, so my answer is definitely not the one 
> you should rely on.
> 
> But, it seems that, submitting multiple instances at once will result in 
> submitting an invalid XML. Each instance document is a valid XML, but 
> once we put two instance documents together they become invalid - they 
> do not have a common root element.
> 
> Now about your example with messages. I had a similar problem. The 
> instance data were sent to server where they had to pass through 
> validation (XMLSchema and also domain-specific validation, such check 
> for unique values and so on). I had to let the user know about those 
> validation errors. What I've done was:
> 
> I've made an <instance id="errorList">. The <submission> element was as 
> follows: <submission replace="instance" instance="errorList">.
> 
> The server response consisted of <error> elements wrapped in the root 
> <errorList> element - so I could show server-side validation errors to 
> the user.
> 
> Again, it is possible that I just get you (and your problem) wrong...
> 
> Hope my answer was of interest. Victor.
>

Received on Friday, 22 September 2006 07:46:28 UTC