struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arron Bates" <struts-...@keyboardmonkey.com>
Subject Re: New Development... PipelineAction/ProcessActions capability.
Date Wed, 07 May 2003 10:16:48 GMT
Mate, I haven't actually read your idea yet, because all I can say is that
you're going to have to watch the list like a hawk to get your idea/code through.

Why?...

I have no doubt that at least half of the developer list is jumpin up and
down, like kids waiting to use an occupied toilet, for 1.1 to fly as a release
so they can get relief on some new funky features.

They know who they are...  :P

You'll have to bring it back up too. Just to make sure you get your input in
there, 'cause when it happens developers go a little blind while implementing
their fun stuff (development version to the other way of going blind). Fact
is, some of them already have working implementations on ideas (I know Martin
does at least), and I'm sure one of the ideas will cross the path of your
pipeline implementation. I have a small one myself, it's a little too tied
into a small form/bean framework, but it's gettin the job done (and so sweet
with the nested tags).

There's a whole lot of "relief" going to happen after the release. It happened
after previous releases, it'll happen again. It shall be fun.


Arron.



> 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


Mime
View raw message