What you are saying is exactly why I am proposing. All of my current Action Classes are fairly simple. That is why I am proposing this. If all of my logic is managed outside of my Action and the action class is merely responding to data provided by those "beans" and passing data into various scopes to supply to the page then it seems to make sense that in a large number of situations you can define what processing needs to happen to that data without having to write an Action class or at least manage the mundane portions with xml definitions.
Let me provide an example: Say I have a website page that uses a shopping cart module (module being a jar of classes) that I created and a dynamic content module. The shopping cart needs to prepare data for the view and the dynamic content needs to prepare data for the view. Both of these modules need to process and prepare different objects for the view. Now each business object process will be the same no matter what page I am going to. All they are doing is responding to information passed in the query. But, say I have a page that needs to prepare objects for the dynamic content and the not the shopping cart. Should I have to write a new Action class to populate the context for the coming view or could I just configure a processing path to "invoke methods on business objects, load some context with whatever the jsp needs" in a "process class". You see all the process would do is perform common tasks without having to compile code. It really comes down to a matter of ease of use and implementation. I build commerce sites for small to midsize companies. If I can place my jars onto the server configure a few xml files and plug my tags into my view then I am all for it. If I have to write custom classes to meld all of my modules together then that doesn't really fit the bill. Let me be clear... I recognize that Actions aren't beans. Beans are specific they get and prepare the data. Actions just shuffle requests and populate contexts. I am just talking about making it easier to predefine and set up a process of common business object requests that can be used from an action. Also, I am NOT talking about servlet chaining. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Hal Deadman [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 4:58 PM To: 'Struts Developers List' Subject: RE: Struts Improvement Proposal: Logic Extensibility It sounds like what your trying to do falls outside of the Struts mandate to aid in the VC of an MVC application. Action classes aren't supposed to do any processing themselves, they just invoke methods on business objects, load some context with whatever the jsp needs, and return forwards. If you want some sort of XML driven processing engine for your business logic, that is outside the scope of Struts. Action classes should be extremely simple, and there will be lots of them, one or two per jsp. You shouldn't try to hard to re-use them. Re-use your business objects from different action classes, make those modular. > -----Original Message----- > From: Phase Web and Multimedia [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 6:36 PM > To: Struts Developers List > Subject: RE: Struts Improvement Proposal: Logic Extensibility > > > 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]> -- 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]>
