You are correct, it does sound like an Action class and really it would be in many ways. But, The difference is that it does not forward anywhere it merely performs data preparation and processing without having to bounce around to several Action classes. The Action uses the process chain defined in the process.xml doc to prepare data for the view. The action could still do specific functions that it needs to do to then route to the proper view.
My thoughts were also that the processing of the Process chain could be specified to happen either pre or post (not sure though, I haven't gotten that far in my thoughts). I imagine also there might be some conditional issues. But, that is why I don't want to make it an Action class. It is possible though that maybe this would be taken further. I just think that we have to be able to reuse more logic easier. The current structure requires a fair amount of predertermination and not quite enough modularity. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 3:41 PM To: Struts Developers List Subject: RE: Struts Improvement Proposal: Logic Extensibility 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
