Well, in pseudo-code, here's basically what popped into my head after
your first message:
public class ProcessorAction extends Action {
private Action[] getProcessActions(ActionMapping mapping, ...) {
// this method would get the name of the process group
// specified for the mapping, create an instance of each
// process action configured for it and return them in an array
}
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse respone) {
Action[] processActions = getProcessActions(mappping, ...);
for (int i = 0; i < processActions.length; i++) {
ActionForward forward = processActions[i].perform(mapping, form,
request, response);
if (forward != null) return forward;
}
return null;
}
}
Then you could extend ProcessorAction and override perform to do
additional processing before or after the process chain...or you could
just use ProcessorAction directly for all your mappings and add Actions
that do the additional processing to the beginning or the end of the
chain.
Would that do what you want? Obviously the real work would be mostly in
the getProcessActions method, but even that would probably be pretty
simple once you've loaded and parsed the config file.
--
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 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: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]>
