>>1:There is no overlap as there does not seem to be any development >>going on about WorkFlow area in struts.
>I think you are correct; people seem to be gravitating to struts-workflow. This makes my life easier now that I know there is no overlap. >I'm not sure which of the above you'd like to resolve to make more >planning. I think (1) is a non-issue; (2) should be deferred until >someone has a use-case for it, and (3) -- well, we're going to work >on moving the commons-chain based request processor into the Struts >core shortly after we deal with migrating Struts to a TLP. But it >works enough right now that you could probably begin exploring using >it for Struts-Workflow. My main confusion was about planning for next major release as it has to be inline with Struts API. So it looks like commons-chain based request processor is the way to go. I will start work on it as soon as I am finished with migration of the workflow-extension to source forge. >I'm interested in both chain and workflow, >so you might be able to con me into helping out a little bit 8^) Joe, if you are interested you are more than welcome to join.Any helping hands are more than welcome, especially since I have been tied with my current project for last couple of months and have not been able to move forward the way I would have liked to. I am in the process of deciding the roadmap/any missing features/enhancements. One of the ideas I have picked up recently on this list was from Craig's mail (about continuation) <snip> The most important feature that [workflow] includes, but is not present in [chain], is the idea that is formally known as a "continuation" -- you can describe a single flow of commands that (if you're building a webapp) requires more than one HTTP interaction with the client. </snip> So if we can extend the workflow extension to provide support to really define reusable workflows(or continuations) which can be used like actionForwards from struts actions, that will make the package really complete. Shirish. -----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 3:41 PM To: Struts Developers List Subject: struts-workflow (Re: OT: Struts JSR?) >1:There is no overlap as there does not seem to be any development >going on about WorkFlow area in struts. I think you are correct; people seem to be gravitating to struts-workflow. >2:While brousing through struts-dev archive, I came aross many >threads where the topic of a workflow like concept was discussed.But >nobody seems to have taken this up any further,apart from a mail >where in craig has mentioned that he would like to implement a >workflow engine where the scriptign languages may be used to define >the workflow.he has also mentioned using jelly for the same. > >But for me, the struts-workflow is more like a wizard >implementation,not a real workflow processing engine.SO I am still >not clear where jelly like packages may help.But may be I am just >being naive. I think it's true that in a wizard scenario, scripting is less likely to be needed. Insofar as one would want to use scripting, I'd probably advocate for a BSF implementation rather than Jelly, so that people can script in any language they want. (Well, actually, I don't think there's a Jelly BSF engine, but I don't think that many people want to script in Jelly either.) >3:The mention of the commons chainning for integrating expernal >packages like workflow so that the processing can be intercepted at >perticular points and customised.This soundds very interesting >concept and very suitable for the workflow requirement.I have not >invested much time into this perticular aspect but plan to do so.And >I also have a feeling that the future direction for the workflow >extension shuld be to move towards the usage of the commons >chainning package. I haven't come up to speed on struts-workflow, although I've been wanting to for a while. I remember that Matthias was one of the people who really wanted to see a composable request processing chain, since right now Struts-Workflow has to extend RequestProcessor. It seems likely that the fit will be pretty natural. >So this leaves me where I started.Very unclear about the direction >the struts is going to take in this regard.And very unclear about >how to plan the next major enhancement for the extension. I'm not sure which of the above you'd like to resolve to make more planning. I think (1) is a non-issue; (2) should be deferred until someone has a use-case for it, and (3) -- well, we're going to work on moving the commons-chain based request processor into the Struts core shortly after we deal with migrating Struts to a TLP. But it works enough right now that you could probably begin exploring using it for Struts-Workflow. I'm interested in both chain and workflow, so you might be able to con me into helping out a little bit 8^) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
