Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
From: "Brandon Goodin" <mail@phase.ws>
To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Subject: RE: New Development... PipelineAction/ProcessActions capability.
Date: Wed, 7 May 2003 08:25:49 -0600
Message-ID: <MCEFJGLDHNNMPENCIDECMEKEFGAA.mail@phase.ws>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Law15-F82t3HvoFOAmE00003165@hotmail.com>
Importance: Normal

>How does this compare to using Filters?  Redesigning Struts as a set of
>Filters is an idea on the table for 2.0.

You can't ask this question and expect me to hold my tongue until the
release is out ;-). Whether or not Filters is used is irrelevant. Even with
Filters this type process pipeline would be important to have. Configuring
filters in a J2EE environment is an all or none kinda thing. All requests go
through all Filters unless some logic along the way says don't go any
further. So in regards to setting up a controller that handles all requests
in a common manner... Filters work great. But, when we are talking about
mapping custom logic patterns, Filters don't provide enough fine-grained
process control. In order to process logic patterns there is a need for
fine-grained process management that even Filters will not provide at this
point.

>IMO, this is not the right time to
>be discussing this issue because it distracts us from releasing 1.1.
Well, I haven't seen anything I can do to help get 1.1. out the door. If I
did I would help. Also, I am not just sitting around coming up with wrenches
to throw in the cogs of Struts 1.1. What I am offering is a need in the
community. So, regardless of release status we should never squash
discussion of needed functionality. If we deal with it now, then when 1.1 is
out we will have some useful new features slated and ready to go for 1.2.
Thought towards future improvements stimulates ambition. I am very
interested in helping to get 1.1 out the door. But, I see nothing I can do
to speed that along. So, I am increasing my niche productivity and
submitting it to the community.

>This also proves that most developers are uninterested in fixing bugs and
more
>interested in developing new features :-).
Not true. I am very interested in fixing Bugs and getting 1.1 out the door.
But, everything that I have seen in the Bug Reports indicates that someone
is working on it. My time (and your's) is very valuable and to be committing
time to something that is already being taken care of doesn't make sense.
Besides, I haven't seen any major outstanding Bugs other than DBCP stuff.
The DBCP releasees and problems seem to be handled by others. I watch for
the Bug Reports that come out and eagerly search for areas where I can offer
assistance. I think I characterize many others here.

Also, I think there are a several bogus bug reports that are shoveled into
the Struts Bug Report system. I assume theses are usually due to newbie
ignorance or by someone who didn't take the time to understand the source or
ask questions first. Solution? If there is a glaring bug that needs to be
fixed, broadcast for help more clearly. Someone needs to sound the alarm and
say, "HEY BUG A,B,C,D absolutely need to be fixed. Get to work, coder dudes,
before our ship sinks." :-D

Brandon Goodin

-----Original Message-----
From: David Graham [mailto:dgraham1980@hotmail.com]
Sent: Wednesday, May 07, 2003 7:44 AM
To: struts-dev@jakarta.apache.org
Subject: Re: New Development... PipelineAction/ProcessActions
capability.


Brandon,
How does this compare to using Filters?  Redesigning Struts as a set of
Filters is an idea on the table for 2.0.  IMO, this is not the right time to
be discussing this issue because it distracts us from releasing 1.1.  This
also proves that most developers are uninterested in fixing bugs and more
interested in developing new features :-).

David

>From: "Brandon Goodin" <mail@phase.ws>
>Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
>To: "Struts Developers List" <struts-dev@jakarta.apache.org>
>Subject: New Development... PipelineAction/ProcessActions capability.
>Date: Wed, 7 May 2003 00:47:39 -0600
>
>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
>

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


---------------------------------------------------------------------
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