Does the interface of a Process differ at all from Action? This sounds like something that could possibly be implemented now by making a ChainingAction or some such that simply called the perform method of a (configurable) list of other action classes. How does the servlet determine the view to ultimately forward to? I could imagine either using the return value of the last Process or using the first non-null return value if you wanted to allow intermediate steps to break out of the process. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863
> -----Original Message----- > From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 5:32 PM > To: Struts Developers List > Subject: Struts Improvement Proposal: Logic Extensibility > > > Okay here is the idea I proposed earlier ("Struts (MVC) > Shortcomings?") in more solid thought. > > My hope in this is to provide an non-hard-coding mechanism to > take advantage of reusable logic without having to forward > around to a bunch of Action classes (which doesn't work anyways). > > Here is my proposal: > > An action mapping could have an associated Process Config > specified in the <set-property> of the action class. > Something like: <set-property name="processor" value="processa" /> > > An associated config file called processor.xml could be set > up to define process patterns that have names associated with > the value attribute of the set-property. Something like: <processor> > <process-group name="processa"> > <process-action name="com.mydomain.ProcessThisA"> > <process-action name="com.mydomain.ProcessThisB"> > </process-group> > <process-groupname="processb"> > <process-action name="com.mydomain.ProcessThisB"> > <process-action name="com.mydomain.ProcessThisC"> > </process-group> > <process-groupname="processd"> > <process-action name="com.mydomain.ProcessThisX"> > <process-action name="com.mydomain.ProcessThisC"> > <process-action name="com.mydomain.ProcessThisN"> > </process-group> > </processor> > > This config info could be placed into the Application Scope > at the app startup using the plugin mechanism of Struts 1.1. > > When an Action is called it would look to see what "process > group" it needs to call and using reflection to perform the > specified chain of processing in the order specified in the > process-groupname config. > > A process class would conform to an interface and would have > access to everything that the Action has access to. This way > any errors or scoped beans/Attributes that need to be set can > be set from within the process class. Also, the process class > could access other logic beans for sql and such. > > Any unique coding that needs to happen can still be contained > in an Action class. But for code that is reusable. This would > be very nice. > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > -----Original Message----- > From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 1:25 PM > To: Struts Dev; Struts User > Subject: Struts (MVC) Shortcomings? > > > I am throwing this post out there in the hopes that it will > either spawn a solid answer or at least discussion towards > addressing these issues that I am facing with MVC/Struts. So, > here I go... > > It is an issue I think is kind of addressed with Plugins but > gives no inline processing options. > > The issue becomes one of preparing data for the view without > having to write an Action Class for every possible page > someone might view. For example I have a shopping cart and I > have dynamic content that is produced seperate from the > shopping cart. The dynamic content shows up side by side with > the shopping cart content. I would have to produce an Action > class for that particular scenario in order to prepare data > for the shopping cart and the dynamic content. > > Wouldn't it be easier if there were a way to allow inline > processing, like an internal struts filter, that could be > configured in an xml file and would pass the request through > a processing that could prepare different data combinations > without having to hardcode everything. > > So in my afformentioned scenario I would pass the request > through some filtering process (I imagine it would be an > interface) that is predefined in an xml doc and then provide > the data to the page for display. For many cases I wouldn't > have to touch the action class. Conditional info can be > contained within the filters (a login bean of sorts). The > advantage of doing this over using Filters (2.3/1.2) is that > you can configure it within struts on specific Action Classes > or maybe url patterns and define the order of processing in > an xml doc. > > So then you could produce a custom action class and assign > common processing to the Action class without having to touch > a stitch of code or use a generic class and give it common > processing requirements. I know this is probably an > oversimplification. But, it doesn't seem entirely impossible. > I would be willing to work on this if I though it would be > possible to have it included into struts in the future. Also, > if someone is doing this already. I would love to get my > grubby fingers on it. > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > > -- > To unsubscribe, e-mail: > <mailto:struts-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:struts-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:struts-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
