W3C home > Mailing lists > Public > www-forms@w3.org > September 2006

Re: multiple instance/model submission

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 22 Sep 2006 11:38:46 +0100
Message-ID: <640dd5060609220338u5495a619l325c41d712375c9@mail.gmail.com>
To: www-forms@w3.org

Hi Jason,

I saw your post, but I would just flag up that when you sent your
message most of the people on the working group had just come back
from over a week of discussing XForms at a face-to-face meeting.
(Don't worry...it was in Venice, so they won't be expecting any
sympathy...just saying why response wasn't immediate.)

For myself, the reason I didn't answer straight away is because there
are actually two ways to look at this, and you prompted me to ponder
them both. One concerns the philosophical/design issues, and the other
relates to the practicalities of how exactly you do what you are
trying to do

On the design question, I agree that it would be great if one model
could appear to be one 'object' (let's say DOM to give us a mental
picture, but it needn't be a DOM). But that is not the case today, so
we need to look at how you can achieve what you want in some other
way.

The easiest way is using the approach outlined by Erik, which is to
use insert and delete to move trees of nodes around and create the
more complex models that you need. That would be not unlike the
technique you might use to handle SOAP messages; you might create an
instance that contains a SOAP envelope, and then copy the data you
want to send into the payload, from some other instance.

However, there is another approach that could be taken to the kind of
'architecture' that you are describing, and we used this for one of
our customers. We designed a system that uses OpenWFE as the workflow
engine, and eXist as the data store, and we decided in the end to keep
the data and the work items *very* separate. Each workflow item
contains one or more URLs to indicate the data that is relevant to
them, and since eXist has a nice RESTful interface, this becomes a
direct map to the data to be used. We found this better than the ID
approach (which as you say is awkward), since it means that we don't
need any other information than the URL to interact with the data, and
we can even move the data to another location, replace eXist with a
different data store, and so on.

The main reason we did this though, was that the workflow boundaries
didn't always mirror the user interaction boundaries. For example, if
someone was creating an application for a mortgage or loan, say, then
they may save that application a number of times before they have
completed it, as they collect the data the need. The workflow need
only be advanced at the point where they complete the application and
press 'Apply Now', but the database may need to be updated many times
during the course of the form-filling.

But as you have pointed out, keeping the data and the workflow
separate means that the form needs to 'know' about all possible
permutations of the data, and that is painful. Our first cut ended up
with a form that was about 800k long! It wasn't too bad running in
formsPlayer (although slow to load), but in our Ajax form-engine it
ran like a dog. However, by adding support for dynamic XIncludes (via
xf:load, as I've described before), we found that we could get the
response times we wanted, and flexibly break up the forms. And
although we haven't gone this final step yet, it also creates the
possibility of the sub-form for the data also being passed as a URL in
the work item.

In summary, on the downside I am saying that 'out of the box', XForms
doesn't really lend itself to workflow-style applications; but on the
upside, with some small tweaks it can be made to do so, and with these
small tweaks XForms becomes an incredibly powerful addition to a
workflow-based application.

Regards,

Mark

> ok, from the deafening silence from my previous post I can only assume
> that my query was either
> a: completely ridiculous - perhaps someone might be kind enough to
> highlight why for me?
> b: nobody had a clue what I meant
> c: nobody cared enough to respond
> d: nobody read it at all.
>
> for those that missed it my query was this:
> Is there a way to submit multiple instances as a single submission? I
> dont just mean a trigger element with multiple submissions, but so that
> the data all arrives as part of the same post?
> I have instance data that I dont want to modify, and I'm trying to
> manage a workflow via jbpm with messages etc being transmitted separate
> to the main instance. I'd like to be able to handle more than a single
> instance - or even a model for that matter (can you submit a model? if
> not why not?) - can it be done?
>
> to clarify my particular case this is whats going on.
> I have xforms that are submitting data. That data is to be
> routed/rerouted with appropriate ancillary messaging and info etc by a
> workflow management system - in my case jbpm. I want to keep the data
> I'm interested in as a single xforms Instance - but I'd like to
> associate arbitrary 2nd/3rd/... Instances so that I can keep response
> messages and workflow related detail separate from the actual Data
> detail that I will actually finally store/do something with. To do this
> I really need a way to submit multiple instances to a server and have
> them all be associated with the same submission. Is there a way to do
> this currently?
>
> eg:
> lets say I have instance data:
> <somedata>my data
> </somedata>
>
> and it gets submitted via an xform and requires review by at least 1
> person. so I have a second form that knows how to read this data and
> poses the question "accept" or "Reject" and allows a simple text message
> to be associated with the response (not an unusual situation I think).
> I want to put this message info into another instance. That way my
> xforms dont all need to know about some schema that contains arbitrary
> elements that are only useful during a workflow. but I can have
> "workflow aware" forms that expect and can load this extra data as required.
> Is there a better approach?
> Should I be thinking differently?
> How can I currently send 2 or more instances as the same posted package
> so that the server knows they should be kept together? do I have to try
> to maintain with some kind of tracking numbers? sounds horrid.
> just being able to send an entire model in 1 hit would be very helpful,
> but I can see that it would also be handy to be able to specify multiple
> models for submission too.
>
> any thoughts?
>
> Thanks
> Jason.
>
>
>
>
>
>
>
>
>


-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Friday, 22 September 2006 10:39:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT