You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by ni...@uk.pwcglobal.com on 2001/07/25 11:23:45 UTC
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: struts-user@jakarta.apache.org
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.
Re: Thoughts on Workflow and multiple devices...
Posted by Nic Hobbs <ni...@yahoo.com>.
Hi Bryan,
Thanks for your comments.
Your concerns are the reason I have been thinking about the multi-page form
support being a specific case of workflow i.e. for web we may only require
one page, but for WAP we may require several etc. As I said I should have
more in a couple of days, but thanks, I'll take your comments into account.
Regards,
Nic
----- Original Message -----
From: "Bryan Field-Elliot" <br...@netmeme.org>
To: <st...@jakarta.apache.org>
Sent: Thursday, July 26, 2001 2:56 PM
Subject: Thoughts on Workflow and multiple devices...
> Some end-user thoughts on the design of the Workflow system --
>
> For the foreseeable future, I'll be building sites which need to be
> accessed from multiple devices, with different presentation
> requirements. This includes the standard desktop browser, but also
> includes WAP, and likely also includes Palm OS web clipping.
>
> To support the same business logic with different presentations, may I
> stress that the Workflow piece be designed to be as "MVC-ish" as the
> rest of Struts.
>
> For example -- perhaps you define logical "activities", composed of
> logical "steps" and logical "pre-" and "post-conditions". But as far as
> mapping these things to actual screens (JSP pages) -- keep in mind that,
> depending upon the device, the developer might want to put all steps
> onto one screen, or split them across multiple screens (or even skip
> certain steps for certain devices). By keeping a loose coupling between
> JSP pages and the logical definition of the workflow (and by allowing
> the flexibility of combining or splitting steps among pages), I'll have
> better support for this kind of UI problem.
>
> Thanks,
>
> Bryan
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
RE: and
Posted by Aaron Ravenberg <ar...@benefitsxml.com>.
I firgured out thx, was looking at the wrong tag description :)
- Aaron
-----Original Message-----
From: Aaron Ravenberg [mailto:aravenberg@benefitsxml.com]
Sent: Thursday, July 26, 2001 9:58 AM
To: struts-user@jakarta.apache.org
Subject: <logic:iterate> and <html:option>
Hi all,
I want to use the iterate tag to develop the <html:option> set for a
<html:select>, is there a way to specify the <html:option value="???" > with
the <bean:write name="list" property="value" /> tag that can be used in the
iteration of my webVendorTreeMap?
<html:select property="webVendorKey" name="webVendorKey" >
// iterate TreeMap to develop the options for the select
<logic:iterate id="list" property="webVendorTreeMap" name="FormBean">
<html:option value="???">
// use the key value from the TreeMap to set text display
<bean:write name="list" property="key" />
</html:option>
</logic:iterate>
</html:select>
Thank you,
Aaron
and
Posted by Aaron Ravenberg <ar...@benefitsxml.com>.
Hi all,
I want to use the iterate tag to develop the <html:option> set for a
<html:select>, is there a way to specify the <html:option value="???" > with
the <bean:write name="list" property="value" /> tag that can be used in the
iteration of my webVendorTreeMap?
<html:select property="webVendorKey" name="webVendorKey" >
// iterate TreeMap to develop the options for the select
<logic:iterate id="list" property="webVendorTreeMap" name="FormBean">
<html:option value="???">
// use the key value from the TreeMap to set text display
<bean:write name="list" property="key" />
</html:option>
</logic:iterate>
</html:select>
Thank you,
Aaron
Thoughts on Workflow and multiple devices...
Posted by Bryan Field-Elliot <br...@netmeme.org>.
Some end-user thoughts on the design of the Workflow system --
For the foreseeable future, I'll be building sites which need to be
accessed from multiple devices, with different presentation
requirements. This includes the standard desktop browser, but also
includes WAP, and likely also includes Palm OS web clipping.
To support the same business logic with different presentations, may I
stress that the Workflow piece be designed to be as "MVC-ish" as the
rest of Struts.
For example -- perhaps you define logical "activities", composed of
logical "steps" and logical "pre-" and "post-conditions". But as far as
mapping these things to actual screens (JSP pages) -- keep in mind that,
depending upon the device, the developer might want to put all steps
onto one screen, or split them across multiple screens (or even skip
certain steps for certain devices). By keeping a loose coupling between
JSP pages and the logical definition of the workflow (and by allowing
the flexibility of combining or splitting steps among pages), I'll have
better support for this kind of UI problem.
Thanks,
Bryan
Re: Workflow impasse? and more
Posted by Nic Hobbs <ni...@yahoo.com>.
Thanks Martin.
Time permitting I would still like to bore you with my ha'penny's worth!
I hope to post my ideas on both Workflow and Security in the next few days -
I managed to put aside some time yesterday for reading the specs properly
and as soon as I have cemented my ideas I'll let everyone know ;)
Nic
----- Original Message -----
From: "Martin Cooper" <ma...@tumbleweed.com>
To: <st...@jakarta.apache.org>
Sent: Thursday, July 26, 2001 5:29 AM
Subject: Re: Workflow impasse? and more
> 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
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Workflow impasse? and more
Posted by Martin Cooper <ma...@tumbleweed.com>.
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: <ni...@uk.pwcglobal.com>
To: <st...@jakarta.apache.org>
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:
struts-user@jakarta.apache.org
> 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.
>
>