- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Fri, 22 Sep 2006 11:38:46 +0100
- 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 UTC