Re: multiple instance/model submission

Thanks Mark,
	your insights are always worthwhile!
I'm not keen to build 800k Xforms though - yuk!
-reminds me of a 'thing' I went to the other night. (this is 
significantly off track but interesting none the less - I think) I have 
a friend who is a member of the local .net users group and he invited me 
along to listen to some IBM guy's spiel on Xforms. As it turned out the 
IBM rep didnt really know very much at all on the topic, and was really 
only there to try to get some interest and sell the IBM xforms platform. 
It seems they have built a fairly elaborate xform builder as an Eclipse 
plugin, but it seems to use entirely custom UI tags wrapping the xform. 
So the results look nice, but only if you are using their server or 
their purpose built client, and use their tool to build them (I think - 
please correct me if I'm wrong) - anyway he had one example of a HUGE 
Xform and it made me wonder how you break up a thing like that so that 
teams can share the work (I know they could break it up into smaller 
ones, but they hadn't - and you obviously found that one form was better 
than ten for some reason too?). This thing was massive!

ok - back to the subject at hand.
You saved your various bits & pieces in an eXist repository, so far so 
good, but I'm lost with how you get them there reliably and keep them 
properly related? I can see how you do it once all the data is at the 
server, but after someone's finished interacting with your xform(s) and 
you have multiple submissions to make(is that right?) then how do you 
get them all into eXist and guarantee that you got all the submissions, 
and all of them are properly related to the same particular form 
submission/workflow point?

My plan was/is to have a number of fairly small xforms that each know 
how to do only small portions of things. so as various xforms are built 
and then assigned a workflow, then as each is used they kick off a jbpm 
workflow. I then use a series of other xforms for the various potential 
ui options to manage the workflow at hand, and I might yet dynamically 
build some of these too. My task would be made far simpler if I could 
have somehow managed both the data of interest, and all the ancillary 
working info together, whilst keeping them separate as far as 
reloading/reusing the data goes.
I'm sure by now you understand this so I should probably stop saying it ;-)

Thanks for your input.
Cheers
Jason.



Mark Birbeck wrote:
> 
> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
>

Received on Friday, 22 September 2006 12:02:26 UTC