You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Tom Drake <To...@tavant.com> on 2003/05/07 19:14:07 UTC
RE: Diagram: New Development... PipelineAction/ProcessActions ca
pability.
This looks like a chain of responsibility pattern, analgous to Servlet
Filters. Great idea!
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:18 AM
To: Struts Developers List
Subject: Diagram: New Development... PipelineAction/ProcessActions
capability.
Here is a simple diagram of the process. It is simplistic for a quick visual
snapshot.
http://www.phase.ws/struts/pipeline-diagram.jpg
Brandon Goodin
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:58 AM
To: Struts Developers List
Subject: AW: New Development... PipelineAction/ProcessActions
capability.
I also wanted to emphasis that I am not advocating actions containing
business logic. What I am advocating is making the access to the logic
reusable for different scnearios and eliminating unecessary dependencies.
Brandon Goodin
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:48 AM
To: Struts Developers List
Subject: New Development... PipelineAction/ProcessActions capability.
As a result of reading the TurboM2 MVC framework information I thought this
would be a good time to post this. M2 boasts a flexible configuration and
reuse of event processes components. I am looking to add some of this type
of functionality to Struts. I thought it was interesting that it came up at
this time and that I also have begun laying the groundwork for introducing
this type of flexibility into Struts. Please read on with an open mind. One
of the blessings of being in the Struts community is that we get a lot of
feedback on ideas. But, one of the curses of being in the Struts community
is that we get a lot of feedback on ideas. So, please be constructive and
positive :-D I have a fragile ego... :-))
I know that I may get a bunch of fiery responses about this. But, I have
seen this come up too many times to be considered a bad idea and unworthy of
strong consideration. I see other frameworks implementing this type of
capability. Also, do to the industry I work in this is of massive importance
to me. Anyways, here it goes.
I'm going to be submitting a Pipeline Process Action capability that is
possible as a result of the "ActionForm wrapping/DynaActionForm with
LazyList" support that i recently submitted to the Struts project (yet to be
approved by committers).
I think it the following will be a popular addition to the struts base. I
could be wrong. But, it is NOT action chaining and fits into the struts
model quite well. In other words, it doesn't seek to replace all Actions as
a pipeline process. But, it allows the capability when it is neccessary. I
personally, find the LookupDispatchAction to be invaluable for
Administration type needs and the regular Action class incredible for single
function needs. So, I'm not advocating or trying to throw out those
important blocks of the struts framework. This process I am introducing
probably deals more with information aggregation and delivery to portal type
or public pages.
I work in a company that develops resuable web based products. These
products must be have no dependence upon each other yet be able to work
together. At the same time they should be quick to implement without having
to write a bunch of new code (actually no new code). This feature is ideal
for this scenario. In other words it doesn't make sense to produce an action
to seem together 3 different business logic calls when you can do it with a
simple configuration. We shouldn't have to write the same code over an over
again. Besides, I think that copy and paste coding is considered an
anti-pattern... right?
continuing...
For example:
I have a page that displays user prepared content (cms), a weather report
and stock information. Now, I also have three different jars that I have
created to handle these scenarios independent of each other. So, if I wanted
a page to display the stock report data and it didn't have to prepare
content I could configure it to accomplish that without writing a different
action for every scenario. Then if down the road content management needed
to be added I could do so by making a configuration change and incorporating
the cms capability without writing a new action for it.
The goal, again, being that these "logic components" should be able to
function together and separate. And they should be able to do so without
dependencies on each other. They should be able to be incorporated without
having to create a whole new Action. We can maintain business rules and
process without having to write new Action code and recompile jars, but
rather, reuse these "logic components".
So, each "logic component", which are called ProcessActions, has the ability
to place data into a specific property of the ActionForm. This is where the
DynaActionForm comes in very handy. You can configure the DynaActionForm to
contain a property for the cms data, the stock data and weather data to be
delivered to the page without having to code up an action for every possible
scenario. This is all accomplished by making a form property addition and
adding a ProcessAction to the PipelineAction's process pipeline
configuration. NOTE: The PipelineAction is the name of action used to pass
the ActionForm through the configured process and interpret forwarding
results.
One of the questions you might ask is how to handle errors and forwarding.
Simple... Because the ProcessAction is passed the same parameters as the
Action you have the ability to saveErrors into the request and configure
forwards to interupt the pipeline or allow it to continue. Each
ProcessAction that the PipelineAction succesively calls will have a forward
config associated with it. The configuration might look something like the
following (this is simplified for brevity):
<form-beans>
<form-bean name="mainPageForm">
<form-property name="stockData"
type="com.foo.StockDataBean"/>
<form-property name="weatherData"
type="com.foo.WeatherData"/>
<form-property name="Content"
type="com.foo.ContentBean"/>
<form-bean>
</form-beans>
<action path="/mainPage"
type="org.apache.struts.actions.PipelineAction"
scope="request"
name="mainPageForm">
<processes proceed="success">
<process name="weather">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="weatherFail"/>
</process>
<process name="stock">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="stockFail"/>
</process>
<processes>
<post-processes proceed="success">
<post-process name="content">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="contentFail"/>
</post-process>
</post-processes proceed="success">
<forward name="continue"
redirect="false"
path="doc.mainPage"/>
<forward name="contentFail"
redirect="false"
path="doc.contentFail"/>
<forward name="weatherFail"
redirect="false"
path="doc.weatherFail"/>
<forward name="stockFail"
redirect="false"
path="doc.stockFail"/>
</action>
The following describes what you see above.
...
<processes proceed="success">
...
processes contain the definition of the pipeline and the order of processes.
proceed -- defines the alias that will cause the process to
move to the next process action
...
<process name="stock">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="stockFail"/>
</process>
...
process -- defines the process action and it's possible forwards.
The forwards of the proccess contain an alias that is used by the
PipelineAction to determine which direction it should go as a result of
what is accomplished in the process action. So, interuptions will be
possible.
If all is succesful the proceed alias is given then the next process will be
called until it reaches the end of the process. Then the PipelineAction will
forward according to
the last alias it received from the processes.
...
<post-processes proceed="success">
<post-process name="content">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="contentFail"/>
</post-process>
</post-processes proceed="success">
...
The post-process is used once a particular forward has been determined. This
is important for content management where you do not want to prepare
uneccessary data for a page that will never be reached. So, once you have
the tiles or jsp forward you will be going to you can set up a post-process
mechanism that will only happen once the forward has been determined. This
will follow the same attribute definitions as defined above for the process
element.
The ProcessAction will use the BeanUtils DynaBean capabilities to access
properties of the underlying ActionForm. You can hard-code the ActionForms
that will be sent through each of the defined proceses if you want. This
could be done by using the WrapDynaActionForm functionality I submitted a
few days ago. This would allow hard-coded ActionForm classes (via
WrapDynaActionForm) and DynaActionForm properties to be accessed in the same
way. So, whether you are handing the PipelineAction a DynaActionForm or a
hardcoded ActionForm it will access the properties with the same
get("aProperty")/set("aProperty") syntax. The FormBean gets passed through
pipeline and populated with the neccessary data. So, in the end the only
coding you may have to do is update your struts-config and form-bean and
restart the app. No special action coding compiling scenarios and no
tweaking your production code for each client's particular situation.
I am working this stuff out and it will be posted in a couple days or
sooner.
I do appreciate any feedback.
Thanks,
Brandon Goodin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Diagram: New Development... PipelineAction/ProcessActions capability.
Posted by Brandon Goodin <ma...@phase.ws>.
So... where is it? I sure would like to make some changes to it. Also, it
doesn't appear to have a post process.
Brandon Goodin
-----Original Message-----
From: Daniel Honig [mailto:daniel.honig@objectmachines.com]
Sent: Thursday, May 08, 2003 12:13 AM
To: Struts Developers List
Subject: RE: Diagram: New Development... PipelineAction/ProcessActions
capability.
I thought Karl Baum already wrote this. This conversation is getting to be
so....
Well...."January", so to speak:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg10911.html
-----Original Message-----
From: Tom Drake [mailto:Tom.Drake@tavant.com]
Sent: Wednesday, May 07, 2003 1:14 PM
To: 'Struts Developers List'
Subject: RE: Diagram: New Development... PipelineAction/ProcessActions
capability.
This looks like a chain of responsibility pattern, analgous to Servlet
Filters. Great idea!
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:18 AM
To: Struts Developers List
Subject: Diagram: New Development... PipelineAction/ProcessActions
capability.
Here is a simple diagram of the process. It is simplistic for a quick visual
snapshot.
http://www.phase.ws/struts/pipeline-diagram.jpg
Brandon Goodin
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:58 AM
To: Struts Developers List
Subject: AW: New Development... PipelineAction/ProcessActions
capability.
I also wanted to emphasis that I am not advocating actions containing
business logic. What I am advocating is making the access to the logic
reusable for different scnearios and eliminating unecessary dependencies.
Brandon Goodin
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:48 AM
To: Struts Developers List
Subject: New Development... PipelineAction/ProcessActions capability.
As a result of reading the TurboM2 MVC framework information I thought this
would be a good time to post this. M2 boasts a flexible configuration and
reuse of event processes components. I am looking to add some of this type
of functionality to Struts. I thought it was interesting that it came up at
this time and that I also have begun laying the groundwork for introducing
this type of flexibility into Struts. Please read on with an open mind. One
of the blessings of being in the Struts community is that we get a lot of
feedback on ideas. But, one of the curses of being in the Struts community
is that we get a lot of feedback on ideas. So, please be constructive and
positive :-D I have a fragile ego... :-))
I know that I may get a bunch of fiery responses about this. But, I have
seen this come up too many times to be considered a bad idea and unworthy of
strong consideration. I see other frameworks implementing this type of
capability. Also, do to the industry I work in this is of massive importance
to me. Anyways, here it goes.
I'm going to be submitting a Pipeline Process Action capability that is
possible as a result of the "ActionForm wrapping/DynaActionForm with
LazyList" support that i recently submitted to the Struts project (yet to be
approved by committers).
I think it the following will be a popular addition to the struts base. I
could be wrong. But, it is NOT action chaining and fits into the struts
model quite well. In other words, it doesn't seek to replace all Actions as
a pipeline process. But, it allows the capability when it is neccessary. I
personally, find the LookupDispatchAction to be invaluable for
Administration type needs and the regular Action class incredible for single
function needs. So, I'm not advocating or trying to throw out those
important blocks of the struts framework. This process I am introducing
probably deals more with information aggregation and delivery to portal type
or public pages.
I work in a company that develops resuable web based products. These
products must be have no dependence upon each other yet be able to work
together. At the same time they should be quick to implement without having
to write a bunch of new code (actually no new code). This feature is ideal
for this scenario. In other words it doesn't make sense to produce an action
to seem together 3 different business logic calls when you can do it with a
simple configuration. We shouldn't have to write the same code over an over
again. Besides, I think that copy and paste coding is considered an
anti-pattern... right?
continuing...
For example:
I have a page that displays user prepared content (cms), a weather report
and stock information. Now, I also have three different jars that I have
created to handle these scenarios independent of each other. So, if I wanted
a page to display the stock report data and it didn't have to prepare
content I could configure it to accomplish that without writing a different
action for every scenario. Then if down the road content management needed
to be added I could do so by making a configuration change and incorporating
the cms capability without writing a new action for it.
The goal, again, being that these "logic components" should be able to
function together and separate. And they should be able to do so without
dependencies on each other. They should be able to be incorporated without
having to create a whole new Action. We can maintain business rules and
process without having to write new Action code and recompile jars, but
rather, reuse these "logic components".
So, each "logic component", which are called ProcessActions, has the ability
to place data into a specific property of the ActionForm. This is where the
DynaActionForm comes in very handy. You can configure the DynaActionForm to
contain a property for the cms data, the stock data and weather data to be
delivered to the page without having to code up an action for every possible
scenario. This is all accomplished by making a form property addition and
adding a ProcessAction to the PipelineAction's process pipeline
configuration. NOTE: The PipelineAction is the name of action used to pass
the ActionForm through the configured process and interpret forwarding
results.
One of the questions you might ask is how to handle errors and forwarding.
Simple... Because the ProcessAction is passed the same parameters as the
Action you have the ability to saveErrors into the request and configure
forwards to interupt the pipeline or allow it to continue. Each
ProcessAction that the PipelineAction succesively calls will have a forward
config associated with it. The configuration might look something like the
following (this is simplified for brevity):
<form-beans>
<form-bean name="mainPageForm">
<form-property name="stockData"
type="com.foo.StockDataBean"/>
<form-property name="weatherData"
type="com.foo.WeatherData"/>
<form-property name="Content"
type="com.foo.ContentBean"/>
<form-bean>
</form-beans>
<action path="/mainPage"
type="org.apache.struts.actions.PipelineAction"
scope="request"
name="mainPageForm">
<processes proceed="success">
<process name="weather">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="weatherFail"/>
</process>
<process name="stock">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="stockFail"/>
</process>
<processes>
<post-processes proceed="success">
<post-process name="content">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="contentFail"/>
</post-process>
</post-processes proceed="success">
<forward name="continue"
redirect="false"
path="doc.mainPage"/>
<forward name="contentFail"
redirect="false"
path="doc.contentFail"/>
<forward name="weatherFail"
redirect="false"
path="doc.weatherFail"/>
<forward name="stockFail"
redirect="false"
path="doc.stockFail"/>
</action>
The following describes what you see above.
...
<processes proceed="success">
...
processes contain the definition of the pipeline and the order of processes.
proceed -- defines the alias that will cause the process to
move to the next process action
...
<process name="stock">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="stockFail"/>
</process>
...
process -- defines the process action and it's possible forwards.
The forwards of the proccess contain an alias that is used by the
PipelineAction to determine which direction it should go as a result of
what is accomplished in the process action. So, interuptions will be
possible.
If all is succesful the proceed alias is given then the next process will be
called until it reaches the end of the process. Then the PipelineAction will
forward according to
the last alias it received from the processes.
...
<post-processes proceed="success">
<post-process name="content">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="contentFail"/>
</post-process>
</post-processes proceed="success">
...
The post-process is used once a particular forward has been determined. This
is important for content management where you do not want to prepare
uneccessary data for a page that will never be reached. So, once you have
the tiles or jsp forward you will be going to you can set up a post-process
mechanism that will only happen once the forward has been determined. This
will follow the same attribute definitions as defined above for the process
element.
The ProcessAction will use the BeanUtils DynaBean capabilities to access
properties of the underlying ActionForm. You can hard-code the ActionForms
that will be sent through each of the defined proceses if you want. This
could be done by using the WrapDynaActionForm functionality I submitted a
few days ago. This would allow hard-coded ActionForm classes (via
WrapDynaActionForm) and DynaActionForm properties to be accessed in the same
way. So, whether you are handing the PipelineAction a DynaActionForm or a
hardcoded ActionForm it will access the properties with the same
get("aProperty")/set("aProperty") syntax. The FormBean gets passed through
pipeline and populated with the neccessary data. So, in the end the only
coding you may have to do is update your struts-config and form-bean and
restart the app. No special action coding compiling scenarios and no
tweaking your production code for each client's particular situation.
I am working this stuff out and it will be posted in a couple days or
sooner.
I do appreciate any feedback.
Thanks,
Brandon Goodin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Diagram: New Development... PipelineAction/ProcessActions capability.
Posted by Daniel Honig <da...@objectmachines.com>.
I thought Karl Baum already wrote this. This conversation is getting to be
so....
Well...."January", so to speak:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg10911.html
-----Original Message-----
From: Tom Drake [mailto:Tom.Drake@tavant.com]
Sent: Wednesday, May 07, 2003 1:14 PM
To: 'Struts Developers List'
Subject: RE: Diagram: New Development... PipelineAction/ProcessActions
capability.
This looks like a chain of responsibility pattern, analgous to Servlet
Filters. Great idea!
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:18 AM
To: Struts Developers List
Subject: Diagram: New Development... PipelineAction/ProcessActions
capability.
Here is a simple diagram of the process. It is simplistic for a quick visual
snapshot.
http://www.phase.ws/struts/pipeline-diagram.jpg
Brandon Goodin
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:58 AM
To: Struts Developers List
Subject: AW: New Development... PipelineAction/ProcessActions
capability.
I also wanted to emphasis that I am not advocating actions containing
business logic. What I am advocating is making the access to the logic
reusable for different scnearios and eliminating unecessary dependencies.
Brandon Goodin
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Wednesday, May 07, 2003 12:48 AM
To: Struts Developers List
Subject: New Development... PipelineAction/ProcessActions capability.
As a result of reading the TurboM2 MVC framework information I thought this
would be a good time to post this. M2 boasts a flexible configuration and
reuse of event processes components. I am looking to add some of this type
of functionality to Struts. I thought it was interesting that it came up at
this time and that I also have begun laying the groundwork for introducing
this type of flexibility into Struts. Please read on with an open mind. One
of the blessings of being in the Struts community is that we get a lot of
feedback on ideas. But, one of the curses of being in the Struts community
is that we get a lot of feedback on ideas. So, please be constructive and
positive :-D I have a fragile ego... :-))
I know that I may get a bunch of fiery responses about this. But, I have
seen this come up too many times to be considered a bad idea and unworthy of
strong consideration. I see other frameworks implementing this type of
capability. Also, do to the industry I work in this is of massive importance
to me. Anyways, here it goes.
I'm going to be submitting a Pipeline Process Action capability that is
possible as a result of the "ActionForm wrapping/DynaActionForm with
LazyList" support that i recently submitted to the Struts project (yet to be
approved by committers).
I think it the following will be a popular addition to the struts base. I
could be wrong. But, it is NOT action chaining and fits into the struts
model quite well. In other words, it doesn't seek to replace all Actions as
a pipeline process. But, it allows the capability when it is neccessary. I
personally, find the LookupDispatchAction to be invaluable for
Administration type needs and the regular Action class incredible for single
function needs. So, I'm not advocating or trying to throw out those
important blocks of the struts framework. This process I am introducing
probably deals more with information aggregation and delivery to portal type
or public pages.
I work in a company that develops resuable web based products. These
products must be have no dependence upon each other yet be able to work
together. At the same time they should be quick to implement without having
to write a bunch of new code (actually no new code). This feature is ideal
for this scenario. In other words it doesn't make sense to produce an action
to seem together 3 different business logic calls when you can do it with a
simple configuration. We shouldn't have to write the same code over an over
again. Besides, I think that copy and paste coding is considered an
anti-pattern... right?
continuing...
For example:
I have a page that displays user prepared content (cms), a weather report
and stock information. Now, I also have three different jars that I have
created to handle these scenarios independent of each other. So, if I wanted
a page to display the stock report data and it didn't have to prepare
content I could configure it to accomplish that without writing a different
action for every scenario. Then if down the road content management needed
to be added I could do so by making a configuration change and incorporating
the cms capability without writing a new action for it.
The goal, again, being that these "logic components" should be able to
function together and separate. And they should be able to do so without
dependencies on each other. They should be able to be incorporated without
having to create a whole new Action. We can maintain business rules and
process without having to write new Action code and recompile jars, but
rather, reuse these "logic components".
So, each "logic component", which are called ProcessActions, has the ability
to place data into a specific property of the ActionForm. This is where the
DynaActionForm comes in very handy. You can configure the DynaActionForm to
contain a property for the cms data, the stock data and weather data to be
delivered to the page without having to code up an action for every possible
scenario. This is all accomplished by making a form property addition and
adding a ProcessAction to the PipelineAction's process pipeline
configuration. NOTE: The PipelineAction is the name of action used to pass
the ActionForm through the configured process and interpret forwarding
results.
One of the questions you might ask is how to handle errors and forwarding.
Simple... Because the ProcessAction is passed the same parameters as the
Action you have the ability to saveErrors into the request and configure
forwards to interupt the pipeline or allow it to continue. Each
ProcessAction that the PipelineAction succesively calls will have a forward
config associated with it. The configuration might look something like the
following (this is simplified for brevity):
<form-beans>
<form-bean name="mainPageForm">
<form-property name="stockData"
type="com.foo.StockDataBean"/>
<form-property name="weatherData"
type="com.foo.WeatherData"/>
<form-property name="Content"
type="com.foo.ContentBean"/>
<form-bean>
</form-beans>
<action path="/mainPage"
type="org.apache.struts.actions.PipelineAction"
scope="request"
name="mainPageForm">
<processes proceed="success">
<process name="weather">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="weatherFail"/>
</process>
<process name="stock">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="stockFail"/>
</process>
<processes>
<post-processes proceed="success">
<post-process name="content">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="contentFail"/>
</post-process>
</post-processes proceed="success">
<forward name="continue"
redirect="false"
path="doc.mainPage"/>
<forward name="contentFail"
redirect="false"
path="doc.contentFail"/>
<forward name="weatherFail"
redirect="false"
path="doc.weatherFail"/>
<forward name="stockFail"
redirect="false"
path="doc.stockFail"/>
</action>
The following describes what you see above.
...
<processes proceed="success">
...
processes contain the definition of the pipeline and the order of processes.
proceed -- defines the alias that will cause the process to
move to the next process action
...
<process name="stock">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="stockFail"/>
</process>
...
process -- defines the process action and it's possible forwards.
The forwards of the proccess contain an alias that is used by the
PipelineAction to determine which direction it should go as a result of
what is accomplished in the process action. So, interuptions will be
possible.
If all is succesful the proceed alias is given then the next process will be
called until it reaches the end of the process. Then the PipelineAction will
forward according to
the last alias it received from the processes.
...
<post-processes proceed="success">
<post-process name="content">
<forward name="success"
alias="continue"/>
<forward name="fail"
alias="contentFail"/>
</post-process>
</post-processes proceed="success">
...
The post-process is used once a particular forward has been determined. This
is important for content management where you do not want to prepare
uneccessary data for a page that will never be reached. So, once you have
the tiles or jsp forward you will be going to you can set up a post-process
mechanism that will only happen once the forward has been determined. This
will follow the same attribute definitions as defined above for the process
element.
The ProcessAction will use the BeanUtils DynaBean capabilities to access
properties of the underlying ActionForm. You can hard-code the ActionForms
that will be sent through each of the defined proceses if you want. This
could be done by using the WrapDynaActionForm functionality I submitted a
few days ago. This would allow hard-coded ActionForm classes (via
WrapDynaActionForm) and DynaActionForm properties to be accessed in the same
way. So, whether you are handing the PipelineAction a DynaActionForm or a
hardcoded ActionForm it will access the properties with the same
get("aProperty")/set("aProperty") syntax. The FormBean gets passed through
pipeline and populated with the neccessary data. So, in the end the only
coding you may have to do is update your struts-config and form-bean and
restart the app. No special action coding compiling scenarios and no
tweaking your production code for each client's particular situation.
I am working this stuff out and it will be posted in a couple days or
sooner.
I do appreciate any feedback.
Thanks,
Brandon Goodin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org