- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Fri, 19 Aug 2005 12:14:05 +0100
- To: <jeacott@hardlight.com.au>
- Cc: <www-forms@w3.org>
Hi Jason, Once people move beyond basic forms to serious applications, then the most common questions they raise concern workflow. For example, we are working on a substantial project for a customer where they have a complex workflow defined. But at various points that workflow needs to retrieve information from users. The question becomes, should the workflow pause and give the user a large form, let them fill it in and then only move on when it has the complete results? Or should the workflow break the task into sub-tasks, and therefore give the user many smaller forms -- one for names and addresses, one for the product they want to buy, a different one depending on whether they are a smoker or a non-smoker...and so on. The latter seems to fit more with how people consider workflow engines at the moment, but the former is by far the better experience for the user, and actually easier to manage for the developers. USER EXPERIENCE Treating the whole thing as a high level task gives the user a better experience, since they can then do things like work offline. Filling in a tax return, for example, is the type of thing you might need to do disconnected from a server, since it can take a while. (And it's certainly the kind of thing you *wouldn't* want to do in a traditional HTML form.) DEVELOPMENT It's also easier to manage, since a lot of functionality is encapsulated in the form, which means that you have flexibility in using different back-end systems. One of the (many) really powerful things about XForms is that it talks nice and easily to REST and web services systems, meaning that your 'back-end' gets very clean -- once you have produced the web services that you need, you're more than half-way done. But that of course brings us to your specific question; you are saying that given XForms can express so much of our workflow, why would we want add a further layer to get BPEL to orchestrate? I agree. XForms actually has much of the functionality that you would need to synchronise various actions in the way that you describe. And given that it has an eventing model it is extremely flexible compared to other workflow languages. But all I can say is that, today, we are not there yet. There is work underway on the XForms Working Group to make the submission side into a separate specification that could stand alone. This will take us a long way in the direction you want, since it could easily be implemented in non-client systems. And what you would also need would be for XForms to have the ability to be 'paused' whilst waiting for external input, such as an email. This is something we are working on with formsPlayer -- in particular the idea of having a list of forms that are at various stages of completion. So although I'm giving you bad news for today -- you probably need to use your workflow engine to orchestrate the things you have described (although I would reflect the status back to a form, so that XForms is still in the driving seat) -- I think the things you are describing are a 'must have' for XForms in the future, and I can certainly say that we plan to help make sure they are implemented over the coming period. Best regards, Mark 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/ > -----Original Message----- > From: www-forms-request@w3.org > [mailto:www-forms-request@w3.org] On Behalf Of Jason Eacott > Sent: 19 August 2005 04:37 > To: Sikora, Gary > Cc: www-forms@w3.org > Subject: RE: xforms and wokflow? > > > ok, > so if I were using formfaces (it shouldn't make any > difference) then how would you approach the problem? > > thanks. > > > Subject: RE: xforms and wokflow? > Date sent: Thu, 18 Aug 2005 23:49:08 -0400 > From: "Sikora, Gary" <gjsikora@progeny.net> > To: <jeacott@hardlight.com.au> > > > Try ForeFaces and we can help ... Cleaner approach ... No division > > between server-side and client-side processing ... > > > > Very respectfully, > > Gary Sikora, FormFaces Product Manager > > > > -----Original Message----- > > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On > > Behalf Of Jason Eacott > > Sent: Thursday, August 18, 2005 22:51 > > To: www-forms@w3.org > > Subject: xforms and wokflow? > > > > > > Hi, > > heres a use case I have to implement, and I'd sday its > a very common > > scenario. I already have an xform that can define and build simple > > xforms (an xform builder form :) ). > > the forms it builds can submit the data to any number of email > > addresses and optionally send it to a data sink too (it > always sends > > it to the sink if no email addresses are assigned) > > > > ok - so now I have to implement a simple workflow into the system. > > after one of these generated forms (just a plain old xform > - we could > > have started the story here but I thought some background > might help - > > hope it doesnt confuse) is made it gets used. > > when a user fills in a form and submits the data, that data > needs to > > be approved before it is stored/emailed. it may need to be > approved by > > multiple folk, so using a workflow engine would make sense. > > > > is there any way to intercept the processing of an xform so > that I can > > accept the submission, send out other emails for > confirmation on other > > forms, and then somehow ask an xform to complete its tasks. > > I can see how I might have one form that just submits, then do some > > serverside logic for the workflow , get another form for > answers, then > > just write code serverside to dump the data into the sink, > and send > > off the various email responses if the data is approved, > but how could > > I achieve this last part by letting the xform do all that > (because it > > already knows how to) I may have an advantage that I am > using chiba - > > serverside xforms implementation, so perhaps I could > instantiate half > > a form serverside or something. > > I run across this kind of thing all the time with xforms, I > don't want > > to break up my simple definition of what data should go where - it > > works well all described in a simple xform, I just want to > insert some > > workflow before it completes. how can i do this kind of > thing without > > getting REALLY ugly? > > > > any thoughts appreciated. > > thanks > > Jason. > > > > > > > >
Received on Friday, 19 August 2005 11:14:38 UTC