RE: multiple instance/model submission

 
Mark writes

"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."

As I have mentioned in many previous posts our interest in XForms is in its
MIP and integration with XML Events, combining this with "other small
tweaks" such as Dojo and Yahoo frameworks allows us to create really "smart"
applications.

I will be shortly releasing some example forms showing how we have gone
about implementing our workflow (BSM) forms.

Kind Regards
Francisco
 
facileXForms - Really AJAX at heart

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Mark Birbeck
Sent: 22 September 2006 11:39
To: www-forms@w3.org
Subject: Re: multiple instance/model submission


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/