Nic,
I've removed your name from the to-do sections per your request. However, I
hope we'll still see your comments and suggestions in these areas as they
develop.
Regarding workflow, I look forward to hearing your thoughts on handling
multi-page forms, and how this might relate to a more general workflow
solution.
--
Martin Cooper
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 25, 2001 2:23 AM
Subject: Re: Workflow impasse? and more
>
> Hi All,
>
> Well I've finally got around to moving my struts subscriptions to a
> different address so I can setup rules etc to manage the number of mails
on
> the lists! Moving them away from my work mail address is a good thing...
>
> So why am I telling you all this? Well I , like Craig T, signed up for
> several areas on the 1.1 Todo list a while back and like Craig have been
> busy with work and being away on holiday and training. So keeping up with
> the volume of mail has been difficult let alone contributing anything
> constructive. So I, like Craig, am going to have to cut down what I am
> involved in to make it fair to others and be able to contribute properly
> without spreading myself too thin. So I am going to back out of the
> following areas for the following reasons:
>
> Standard Validations & Client Side Validations - because I have not
> done the work I expected to in this area and therefore feel I probably
> shouldn't butt in on these!
> EJB Design Patterns - for similar reasons. Although I have been
> working with EJBs I think there are others who are better qualified to
lead
> this piece.
>
>
> I will of course contribute where possible to these areas but feel I
> am unable to lead them or take a direct role in designing/writing these.
>
>
> Which leaves the following:
> Multi-page form support - I think this really may tie in with
the
> Workflow processing
> Workflow processing - I am working on workflow at the moment
from
> a 'backend' perspective i.e. at the EJB layer which I hope will help
cement
> my ideas for the Struts workflow. More on this later.
> Role-based Action Execution - I have been looking at JAAS and
> security in general and need to look into the specs a bit more to
> understand what _must_ be supported by containers and what
> _tends_ to be supported before we make a decision on exactly where to go
> with this. Again more later.
>
> I hope this will enable to contribute more than I have in the past and get
> things moving. Apologies for anyone expecting me to take the others areas
> through to completion.
>
> So on to Workflow.
> As Ted suggests I also believe the fundamentals are there in the
> framework already. There have been several discussions about exactly what
> the workflow piece is but I think Ted's implications are the best. I don't
> think we are trying to design something that is a GUI nor are we trying to
> make something that conforms to standards which are in their infancy. This
> is not to say that support for products ( I think Visio for instance was
> suggested) should not come later but I think this is in addition to the
> underlying functionality which is to link Actions together to form a
> business process with pre- and post-requirements. This is where the
thought
> on the multi-page forms comes in. I have been thinking about this a lot
> lately and have a few ways of doing this which when I cement them a little
> more will post here.
>
> I think we need to get down a solid set of requirements ( I think Ted's
are
> a good start) and be clear what we are trying to achieve (I have tried to
> outline my view above) before we can proceed and I will take a proper look
> at the code examples Ted outlines in his mail. Much of the discussion so
> far has been on several tracks all under the global term 'workflow'.
> (Please don't take any of this as criticism - I am aware I haven't
> contributed much up until now - just observations and an attempt to get
> this going). So any comments on what we are trying to achieve and how?
(and
> I am waiting for the slap too... ;)
>
> And then the security thing....
>
> I have been primarily working with BEA Weblogic and working on a banking
> system so security has been key. We have had various discussions with BEA
> and finally got some answers so I have a clear idea of how BEA do things
> and how we may be able to fit this in to struts. What is currently not
> clear and Craig M has alluded to before is that the specs aren't really
> explicit in this area and each application server tends to do things in
its
> own way. So I intend to look at the specs a little more to see what they
> should at least all support and then work on whether we want to link
> something into that or produce a struts specific implementation ( which
> obviously should abstract things so that people can plug in their app
> server specific stuff if necessary, although Struts is unlikely, at least
> at this stage, to support this 'out-of-the-box'.) As the saying
goes...I'll
> be back...
>
> I hope I haven't stepped on anyone's toes here and I hope I can contribute
> properly in the future which I haven't been able to up until now due to
> other commitments. Could I ask someone who has commiter privs to remove me
> from the areas above on the todo list? Many thanks,
>
> Kind regards and keep up the good work!
>
> Nic
>
>
>
>
>
>
>
> Ted Husted
> <husted@apach To:
[EMAIL PROTECTED]
> e.org> cc:
> Subject: Re: Workflow
impasse? New ideas.
> 24/07/2001
> 12:24
> Please
> respond to
> struts-user
>
>
>
>
>
> As it stands, the Struts ActionMappings are already very nearly
> workflows. To close the loop, I believe we only need a few things.
>
> 1) A way to declare prerequesite actions.
> 2) A way to bookmark an Action, so the workflows can be rentrant.
> 3) A way to declare the html:form Action path at runtime.
>
> Given these capabilities, and a simple support structure, a set of
> ActionMappings can be linked together to form a robust workflow that can
> reuse input forms.
>
> Matthias Bauer has code for (1),
>
> <
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01685.html
> >
>
> and Martin Cooper has a plan for ActionRequests that sound good for (2).
>
> <
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg02398.html
> >
>
> As for (3), I have a hack in place now,
>
> <
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg02374.html
> >
>
> but was waiting on Martin's ActionRequests before thinking seriously
> about integrating the mechanism into the framework.
>
> Craig is also reviewing some "airplane notes"
>
> <
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg02439.html
> >
>
> he has about a scripting mechanism that might also be used for
> workflows.
>
> In the end, I think a workflow will look like another set of
> ActionMappings, and the Action will just contain some extra logic for
> returning the correct ActionForward if the flow gets out of synch.
>
> In the meantime, I do like the ideas that are coming up on this thread.
>
>
> > Jonathan Asbell wrote:
> >
> > Hello all. I just got back and was reading the e-mails about
> > workflows. By the tone and lack of dialog I think that we are not
> > sure how we really want to design workflows still. So lets have more
> > discussion on the subject. When its clearer we will better know what
> > we want to do.
>
>
> ----------------------------------------------------------------
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you
received
> this in error, please contact the sender and delete the material from any
> computer.
>
>
