Re: ActionContext [WAS: RE: composable RequestProcessor]

I do the same thing in bP! One Context/Event object. Much simpler. Also, the signature can then support TilesAction signature, , etc. .V Peter A. Pilgrim wrote: Andrew Hill wrote: I'd even like create a new execute(StrutsRequestContext) method in the default Action class, that simple calls the o

Re: ActionContext [WAS: RE: composable RequestProcessor]

Andrew Hill wrote: I'd even like create a new execute(StrutsRequestContext) method in the default Action class, that simple calls the old execute(m, f, r, r) (for backwards compatibility). Im doing this in my app - though the execute signature remains the same. Most of my actions extend some abst

Re: Struts Module [RE: composable RequestProcessor]

And we'll put in work on the bugs. We haven't run into any, and presumably there aren't any right now or we wouldn't be cutting a release candidate. But I'll keep my eye out for discussions about where they need improvement. Search bugzilla for bugs marked LATER and you'll find module problems.

Re: Struts Module [RE: composable RequestProcessor]

So Modules are effectively dead(wood). Is that what you are saying? Not at all. Modules are buggy because no one is around that seems willing to support them. I try to fix them as best I can but I don't use modules which makes my motivation fairly low. Eddie Bush used to work on module issues

Re: Struts Module [RE: composable RequestProcessor]

At 18:06 +0100 6/5/03, PILGRIM, Peter, FM wrote: So Modules are effectively dead(wood). Is that what you are saying? The only problem I think I have with modules (am I have never used in anger) is that they do not inherit resources or the actions of the default module. If they did writing Expresso

Struts Module [RE: composable RequestProcessor]

> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > > David Graham wrote: > > This reminds me of modules where they sounded like a great > idea and then > > there's nobody to support the bugs. > > Amen to that, brother. > > http://nagoya.apache.org/eyebrowse/ReadMsg?lis

Re: ActionContext [WAS: RE: composable RequestProcessor]

Andrew Hill wrote: Im doing this in my app - though the execute signature remains the same. Most of my actions extend some abstract action classes, and most of the hooks the subclass overrides are passed an ActionContext bean (which simply has getters for the request,response, mapping etc...). Save

RE: composable RequestProcessor

At 14:44 +0100 6/5/03, PILGRIM, Peter, FM wrote: This could work well. How does this processor pattern solve the problem where the RequestProcessor stores data member? E.g. The list of Actions recorded against a ModuleConfig. The list of actions is only really used by one process method so it doesn

RE: composable RequestProcessor

At 14:44 +0100 6/5/03, PILGRIM, Peter, FM wrote: This could work well. How does this processor pattern solve the problem where the RequestProcessor stores data member? E.g. The list of Actions recorded against a ModuleConfig. That's a good question. Maybe the interface for processor modules shoul

RE: composable RequestProcessor

> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: 04 June 2003 12:05 > To: Struts Developers List > Subject: Re: composable RequestProcessor > > > I still don't see why processing an "action" request is any different &

RE: composable RequestProcessor

Just thought I'd through an argument out there against using the xml configuration approach as food for thought. On my current application, I have around 12 struts modules. Each is using dynaActionForms, 3 or 4 plugins, and ranging from 10-50 actions. I have several developers who do a great job

ActionContext [WAS: RE: composable RequestProcessor]

tions execute but havent got around to it yet. -Original Message- From: Gary D Ashley Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, 6 June 2003 15:02 To: Struts Developers List Subject: RE: composable RequestProcessor >Maybe the interface for processor modules should >take two a

RE: composable RequestProcessor

>Maybe the interface for processor modules should >take two arguments, a "StrutsRequestContext" like what you described, which >would have these properties: >request >response >mapping >form >path >Then a second object, "StrutsModuleContext" >with these properties, with public accessors, only a pu

Re: composable RequestProcessor

But I guess this is just speculating about hte future. Maybe the best solution is to create a simple composable RequestProcessor for 1.2 and then see what the future might bring? A new RequestProcessor in any form warrants its own point release. 1.2 is already scheduled for a move to commons

Re: composable RequestProcessor

many degrees of freedom. But maybe it's just FUD. Ted pointed out the similarity between the Validator and a composable RequestProcessor. It could be a way to restrict the freedom by defining some sort of dependencies between the processing methods (both by somehow defining a lifecycle, and

Re: composable RequestProcessor

the implication is either the Tiles or RequestProcessor implementations are falling short of the mark. I don't know when a version of Struts based on Filters will be available. But I do know that if someone came up with a implementation of a composable RequestProcessor that worked like the

RE: composable RequestProcessor

To: [EMAIL PROTECTED] Subject: RE: composable RequestProcessor >If we use Filters in lieu of the RP wouldn't that require that we move the >ActionServlet to a filter as well? Where does the ActionServlet fit in to >this? The ActionServlet initializes Struts from the config files but all p

RE: composable RequestProcessor

might be a good thing to retain it. Don't you think? Brandon Goodin -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: RE: composable RequestProcessor >If we use Filters in lieu of the RP wouldn&#

Re: composable RequestProcessor

David Graham wrote: This reminds me of modules where they sounded like a great idea and then there's nobody to support the bugs. Amen to that, brother. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=133116 -Ted. -

RE: composable RequestProcessor

11:44 AM To: [EMAIL PROTECTED] Subject: Re: composable RequestProcessor >David Graham wrote: >>Why should we duplicate the effort of the container inside Struts? > >We often duplicate the effort of the container. Actions duplicate servlets. >Modules duplicate multiple applicatio

RE: composable RequestProcessor

EMAIL PROTECTED] Subject: Re: composable RequestProcessor >David Graham wrote: >>Why should we duplicate the effort of the container inside Struts? > >We often duplicate the effort of the container. Actions duplicate servlets. >Modules duplicate multiple applications. > >In ea

Re: composable RequestProcessor

David Graham wrote: Why should we duplicate the effort of the container inside Struts? We often duplicate the effort of the container. Actions duplicate servlets. Modules duplicate multiple applications. In each of these cases, the effect of the container feature is the same, but the justificat

Re: composable RequestProcessor

David Graham wrote: Why should we duplicate the effort of the container inside Struts? We often duplicate the effort of the container. Actions duplicate servlets. Modules duplicate multiple applications. In each of these cases, the effect of the container feature is the same, but the justifica

RE: Re: composable RequestProcessor

ose on all actions. It is, however, possible to do now, if you need to. Brandon Goodin -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 10:23 AM To: Struts Developers List Subject: RE: Re: composable RequestProcessor I'm not sure why yo

Re: composable RequestProcessor

I'm not convinced that this configuration is Struts' responsibility. If we want to define a chain of methods that will process a request we should be using Filters and web.xml to configure them. Filters are the standard method of doing this and fit in well with our RequestProcessor (RP) method

RE: Re: composable RequestProcessor

itfalls of 'action chaining'. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, 5 June 2003 00:15 To: Struts Developers List Subject: RE: Re: composable RequestProcessor At 9:36 -0600 6/4/03, Brandon Goodin wrote: >That sounds very complex. With V

RE: Re: composable RequestProcessor

At 9:36 -0600 6/4/03, Brandon Goodin wrote: That sounds very complex. With Validator we are dealing with quantifiable results. This is not so cut and dry with RP stuff. With the RP I think we would do best not to add anymore complexity than neccessary. One process should be ignorant of the other un

RE: Re: composable RequestProcessor

PROTECTED] Sent: Wednesday, June 04, 2003 9:19 AM To: Struts Developers List Subject: Re: Re: composable RequestProcessor Just a thought... Would it be possible to take the anology to Validator one step further? Instead of a predefined or configurable lifecycle, would it be possible to let the

RE: Re: composable RequestProcessor

Like targets in Ant... -Original Message- From: Kent Sølvsten Rasmussen [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 June 2003 23:19 To: Struts Developers List Subject: Re: Re: composable RequestProcessor Just a thought... Would it be possible to take the anology to Validator one step

Re: Re: composable RequestProcessor

Just a thought... Would it be possible to take the anology to Validator one step further? Instead of a predefined or configurable lifecycle, would it be possible to let the SubProcessors depend on each other, just like some of the validations "depend" on each other? Maybe the configurationfile

Re: composable RequestProcessor

Joe, I agree that it makes sense to wrap things up on the wiki page. And the status it currently has is a good snapshot of the current situation. We will see how this progresses and when it makes sense to change the wiki pages again. I still need to look at the current request processor code wi

RE: composable RequestProcessor

At 21:14 +0800 6/4/03, Andrew Hill wrote: Just had a look at the updated wiki. Is it just me lacking sleep or are the contents for the singleInterface page and the composableRequestprocessor page kindof in the wrong places? (ie the stuff for composable on the single page and vice versa) I don't thi

RE: composable RequestProcessor

003 7:05 AM > To: Struts Developers List > Subject: Re: composable RequestProcessor > > > I still don't see why processing an "action" request is any different > than processing a "validation" request. > > Formed like the validation, the default

RE: composable RequestProcessor

[mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 June 2003 21:11 To: Struts Developers List Subject: Re: composable RequestProcessor > I just made some more changes to the Wiki to try to point out the lack > of consensus on this issue. (Until this morning it said people felt > one way, and

Re: composable RequestProcessor

I just made some more changes to the Wiki to try to point out the lack of consensus on this issue. (Until this morning it said people felt one way, and Ted just wrote a pretty good argument for thinking about it another way.) This is right. Before Ted's mail I was pretty sure, that the idea o

Re: composable RequestProcessor

I knew that was going to happen. I tried to type the URL from memory and got it wrong. Here's the right one: http://nagoya.apache.org/apachewiki.cgi?RequestProcessor At 7:53 -0500 6/4/03, Joe Germuska wrote: I just made some more changes to the Wiki to try to point out the lack of consensus on

Re: composable RequestProcessor

I just made some more changes to the Wiki to try to point out the lack of consensus on this issue. (Until this morning it said people felt one way, and Ted just wrote a pretty good argument for thinking about it another way.) I strongly encourage people who are really thinking about this to r

Re: composable RequestProcessor

Jeff Robertson wrote: As I just said in a message that probably hasn't made it to you yet, I did need something *sorta* like this enough to actually do it on ActionServlet. At the time nobody paid much attention because a) I didn't put up the code b) It was for Struts 1.0 Now that other people seem

Re: composable RequestProcessor

I still don't see why processing an "action" request is any different than processing a "validation" request. Formed like the validation, the default request chain looks like this: process="processLocale,processContent,processNoCache,processPreprocess,processMapping,processRoles,processActionFor

Re: composable RequestProcessor

Seems like the GIF I attached to my previous mail did not come through. Therefore, the UML diagram can be accessed via the following URL: http://www.livinglogic.de/Struts/requestProcessor.gif - To unsubscribe, e-mail: [EMAIL PRO

Re: composable RequestProcessor

This is a multi-part message in MIME format. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: composable RequestProcessor

During this whole discussion I feel torn back and forth whether to solve this challenge with configuration or in code. One thing we are trying to achieve when going in the configuration direction is the following: Different extensions don't need to know anything of each other and we can (if we

Re: composable RequestProcessor

Ted Husted wrote: Gary D Ashley Jr. wrote: > First, > If the TilesRequestProcessor were to be integrated into > RequestProcessor, and made to play nice when not using Tiles, that > would at least remove one obstacle when trying to extend the request > processor. Since Tiles seems tobe a core stru

RE: composable RequestProcessor

Have any of you explored how XWork/WebWork2 handle any of these situations? Just curious. Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: composable RequestProcessor

Gary D Ashley Jr. wrote: > First, > If the TilesRequestProcessor were to be integrated into > RequestProcessor, and made to play nice when not using Tiles, that > would at least remove one obstacle when trying to extend the request > processor. Since Tiles seems tobe a core struts component now, w

RE: composable RequestProcessor

First, If the TilesRequestProcessor were to be integrated into RequestProcessor, and made to play nice when not using Tiles, that would at least remove one obstacle when trying to extend the request processor. Since Tiles seems to be a core struts component now, would that make since? Or should T

RE: composable RequestProcessor

First, If the TilesRequestProcessor were to be integrated into RequestProcessor, and made to play nice when not using Tiles, that would at least remove one obstacle when trying to extend the request processor. Since Tiles seems to be a core struts component now, would that make since? Or should T

Re: composable RequestProcessor

I don't want to put words in your mouth, but from the discussion, I get the sense that you are focused on deploying a single application. I am focused on meeting your needs in an appropriate way (and playing a bit of devil's advocate). The people who are speaking up here are all those who are tr

Re: composable RequestProcessor

At 14:03 +0200 6/3/03, Matthias Bauer wrote: One thing I am still not clear about is how granular to define which methods can be overwritten and how they are grouped together. I am saying this, because when looking at TilesRequestProcessor you see that it overwrites three methods: processForward

Re: composable RequestProcessor

Somewhere along the way in this discussion, simplicitly was lost. Configuring each method in struts-config and separating RP into many interfaces seems like overkill to me. You lose the ability to truly compose behavior with the struts-config approach. You can't do this in xml: public proces

Re: composable RequestProcessor

sary info, Id prefer this to just having a whole bunch of extra attribute directly hanging off the controller element. -Original Message- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 18:10 To: Struts Developers List Subject: Re: composable RequestProcessor

Re: composable RequestProcessor

From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 18:10 To: Struts Developers List Subject: Re: composable RequestProcessor This driving request processor who selects the instances of the sub request processors should be the one who keeps the members. Every sub request pr

RE: composable RequestProcessor

is to just having a whole bunch of extra attribute directly hanging off the controller element. -Original Message- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 18:10 To: Struts Developers List Subject: Re: composable RequestProcessor > > > >This dri

Re: composable RequestProcessor

This driving request processor who selects the instances of the sub request processors should be the one who keeps the members. Every sub request processor must be allowed to modify these members. Therefore the driving request processor must pass a reference to himself to each method now (like i

RE: composable RequestProcessor

to this that I havent spotted? -Original Message- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 17:48 To: Struts Developers List Subject: Re: composable RequestProcessor > > >Would grouping the interfaces as I have done above actually >solve this

Re: composable RequestProcessor

Joe Germuska wrote: Anyway, enough talk -- who's got some code? :-) If anyone did have some code they wanted to "white board" and share, I could open an area in the Struts Application site on SourceForge, to put it under CVS. http://sourceforge.net/projects/struts -T. --

Re: composable RequestProcessor

Heydtmann, Dirk [ITS] wrote: Similar problem here. For legacy reasons we have to wrap an inhouse framework around Struts which is used by a number of application teams. Since we needed to override some RequestProcessor method, we had to choose between TilesRequestProcessor and RequestProcessor. We

Re: composable RequestProcessor

Matthias Bauer wrote: Again, it hopefully is not Struts 2.0 we are talking of, but Struts 1.2? I'm hoping to get Struts 1.2 out the door long before you guys have this sorted out =:0) Accepting the challenge ;-)) Whether it can be done in the 1.x series or 2.x series would have a lot to

Re: composable RequestProcessor

Would grouping the interfaces as I have done above actually solve this problem? If you have two request processor that implemented my `DispatchRequestProcessorInterface ' as above you would still have the same messy aggregation problems as above, albeit is lesser number of methods to consider. I

Re: composable RequestProcessor

Matthias Bauer wrote: Again, it hopefully is not Struts 2.0 we are talking of, but Struts 1.2? I'm hoping to get Struts 1.2 out the door long before you guys have this sorted out =:0) Whether it can be done in the 1.x series or 2.x series would have a lot to do with whatever you decide to do and

RE: composable RequestProcessor

ion is "what is a request processor?" > > > >(Obviously if both need to override processXXX then there > are going be some > >problems (unless XXX is something that ALSO happens to be amenable to > >chaining) but based on the comments from other people Id &g

Re: composable RequestProcessor

PROTECTED]; [EMAIL PROTECTED] Subject: RE: composable RequestProcessor Well I see little point in defining an interface that simply requires you to implement all the hooks in the RP. It doesnt seem to get us any further than where we are already (well apart from satisfying my compulsive

Re: composable RequestProcessor

It the solution is to sub-divide the request processor into several smaller pieces (and this is what it currently looks like to me), this does not mean that we have to do anything with servlet filters. Therefore this does not need to wait until Struts 2.0. You are correct; I think you just m

Re: composable RequestProcessor

At 8:49 +0100 6/2/03, Mete Kural wrote: Hello Struts developers, I noticed this discussion on how to design the next generation of the Struts RequestProcessor and it got me interested. I have one question to you guys about this subject. Can the next version of RequestProcessor be designed in su

RE: composable RequestProcessor

To: Struts Developers List Subject:Re: composable RequestProcessor The Struts Workflow Extension (http://www.livinglogic.de/Struts/) has exactly the problem you are describing. It needs to overwrite the standard RequestProcessor and the TilesRequestProcessor. In order not to

Re: composable RequestProcessor

At 17:19 +0200 6/2/03, Matthias Bauer wrote: It the solution is to sub-divide the request processor into several smaller pieces (and this is what it currently looks like to me), this does not mean that we have to do anything with servlet filters. Therefore this does not need to wait until Struts

Re: composable RequestProcessor

Hello Struts developers, I noticed this discussion on how to design the next generation of the Struts RequestProcessor and it got me interested. I have one question to you guys about this subject. Can the next version of RequestProcessor be designed in such a way that it will enable developers

Re: composable RequestProcessor

According to the Struts Roadmap at , 2.2 will remain the baseline for all Struts 1.x, and 2.3 will probably be the baseline for Struts 2.0. That page notes that Struts 2.x will probably be using filters, although not specifically in the context of

RE: composable RequestProcessor

believe in the 80/20 rule)) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 22:41 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: composable RequestProcessor >Well I see little point in defining an interface that simply requires you

RE: composable RequestProcessor

-Original Message- > From: Matthias Bauer [mailto:[EMAIL PROTECTED] > Sent: 02 June 2003 15:55 > To: Struts Developers List > Subject: Re: composable RequestProcessor > > > Rephrasing it, would help me, too ;-) > > Brandon Goodin wrote: > > >>The c

Re: composable RequestProcessor

If the list of extension grows (Tiles, Worklfow Extension, Expresso, ...) the number grows exponentially. You need to implement a class for each possible combination of extensions: 1. your extension alone 2. your extension + tiles 3. your extension + workflow 4. your extension + tiles + workf

Re: composable RequestProcessor

Andrew Hill wrote: Well I see little point in defining an interface that simply requires you to implement all the hooks in the RP. It doesnt seem to get us any further than where we are already (well apart from satisfying my compulsive desires for more interfaces!) You need to break it out into mu

RE: composable RequestProcessor

is written to unite the two RPs , such as what MB has had to do to marry workflow and tiles under the current architecture... -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 22:12 To: [EMAIL PROTECTED] Subject: RE: composable RequestProcessor >An i

Re: composable RequestProcessor

If the list of extension grows (Tiles, Worklfow Extension, Expresso, ...) the number grows exponentially. You need to implement a class for each possible combination of extensions: 1. your extension alone 2. your extension + tiles 3. your extension + workflow 4. your extension + tiles + workflo

RE: composable RequestProcessor

> -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: 02 June 2003 15:12 > To: [EMAIL PROTECTED] > Subject: RE: composable RequestProcessor > > > >An interface should be easy to construct aggregated request > processors. >

Re: composable RequestProcessor

Rephrasing it, would help me, too ;-) Brandon Goodin wrote: The controllers that I have seem only subclass one or two methods of the RequestProcessor class itself. Compared your approach and the StrutsChaining guys and realise there are only intercepting the ubiquitous ``execute'' Command method

RE: composable RequestProcessor

Monday, 2 June 2003 22:12 To: [EMAIL PROTECTED] Subject: RE: composable RequestProcessor >An interface should be easy to construct aggregated request processors. >If you are saying > >import org.apache.struts.mythical.RequestProcessorInterface; > >class FooRequestProcesso

Re: composable RequestProcessor

At 8:05 -0600 6/2/03, David Graham wrote: I'm against mimicing Filters because that's the container's job. If we want Filter behavior then we should design the RequestProcessor as a set of Filters. And this is probably a good thing to look at for Struts 2.0 (as I believe Craig had mentioned in

Re: composable RequestProcessor

For two extensions being around this can be accomplished. But as soon as the number of extensions grows beyond 2 (which has already happened) this is fairly impossible. Providing a RequestProcessor interface does not really relieve the situation. Even though it will make it easier to compose

RE: composable RequestProcessor

>The controllers that I have seem only subclass one or two methods >of the RequestProcessor class itself. Compared your approach >and the StrutsChaining guys and realise there are only intercepting >the ubiquitous ``execute'' Command method, and not all ten >`process*Whatever()' methods. Peter, I'

RE: composable RequestProcessor

An interface should be easy to construct aggregated request processors. If you are saying import org.apache.struts.mythical.RequestProcessorInterface; class FooRequestProcessor implements RequestProcessorInterface { RequestProcessInterface tiles = new TilesRequestProcessor(); RequestProc

RE: composable RequestProcessor

> -Original Message- > From: Matthias Bauer [mailto:[EMAIL PROTECTED] > > > I will try to wrap up, what we are up against: The current > RequestProcessor implementation does not support chains of request > processors. So the developer has to decide which request processor to > choose.

Re: composable RequestProcessor

For two extensions being around this can be accomplished. But as soon as the number of extensions grows beyond 2 (which has already happened) this is fairly impossible. Providing a RequestProcessor interface does not really relieve the situation. Even though it will make it easier to compose a

RE: composable RequestProcessor

> -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > > > >If RequestProcessor becomes an interface then you ought invent > >a RequestProcessorManager interface, which is an object > >responsible for managing and invoking request processor. > >In other words we have a mana

RE: composable RequestProcessor

Ok, here is exactly what we use here at Magnet. Please ignore the 1.0-ness. Also excuse the scarcity of Javadocs for the individual methods.. hopefully the stuff at the head of the class explains it. package com.magnetbanking.util.servlet; import java.io.IOException; import javax.servlet.ServletE

RE: composable RequestProcessor

> -Original Message- > > Come to think of it, when is struts going to depend on > servlet 2.3 and no > longer support 2.2? If thats slated for struts 1.2 perhaps > you could ditch > the AS and RP completely and do something with filters? - > though I suppose > you still want to organise

RE: composable RequestProcessor

uess, so the AS/RP dynamic duo would stay but could be implemented as filters. -Original Message- From: Jeff Robertson [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 21:04 To: 'Struts Developers List' Subject: RE: composable RequestProcessor > From: Andrew Hill [mailto:[EMA

Re: composable RequestProcessor

Could be, except if it's not something anyone really wants, we should probably just skip it! The whole question arose simply because one of my colleagues wanted to provide special processing for just processActionForm() and she didn't want to make the decision between extending RequestProcess

RE: composable RequestProcessor

> From: Andrew Hill [mailto:[EMAIL PROTECTED] > Sent: Monday, June 02, 2003 8:54 AM > To: Struts Developers List > Subject: RE: composable RequestProcessor > > > > At this point, I think the main goal is to come up with a decent name > for an interface which Reque

RE: composable RequestProcessor

f thought, as well as the even more diabolical school that thinks "absabludylootly everything should be accessed through an interface". ;->) -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 20:42 To: Struts Developers List Subject: Re:

RE: composable RequestProcessor

> -Original Message- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > > That lead to the current discussion, which is mostly theoretical, > since no one who has spent longer extending RequestProcessor is > clamoring for this kind of complexity. Even if they were clamoring, > no one wou

RE: composable RequestProcessor

A local extension that I made to Struts 1.0 is possibly germane to this discussion. If you don't mind looking at ActionServlet-based code I'll post my work here. I might go ahead and translate it to RequestProcessor. I planned to eventually do this all along, since all it did was override several

Re: composable RequestProcessor

;RequestProcessor" for an interface and not be worried about compatibility with 1.x code. But then, if you see the value of a truly composable RequestProcessor and write one, someone somewhere would probably be interested in it. If you really wanted to, you could do it now by subclassing C

RE: composable RequestProcessor

bject such as processActionForm(). Where the RPs are complementary its not a problem of course. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 17:54 To: Struts Developers List Subject: Re: composable RequestProcessor Peter A. Pil

Re: composable RequestProcessor

Peter A. Pilgrim wrote: > MasterRequestProcessor master = new MasterRequestProcessor(); > master.add( TilesRequestProcessor ); > master.add( FoobarRquestProcessor ); > > Is this it? I would say that this is on the right track. Essentially, each of the process methods represent an extension point o

Re: composable RequestProcessor

I will try to wrap up, what we are up against: The current RequestProcessor implementation does not support chains of request processors. So the developer has to decide which request processor to choose. This brings him into a dilemma, if he wants to use two struts extensions that both implemen

Re: composable RequestProcessor

Joe Germuska wrote: At 16:33 +0100 6/1/03, Peter A. Pilgrim wrote: For Expresso I too have subclassed the TilesRequestProcessor for our own ExpressoRequestProcessor. Can a module have more than one controller? Not the way it is right now, and I'm not sure why you'd need it. I think if you want

Re: composable RequestProcessor

If RequestProcessor becomes an interface then you ought invent a RequestProcessorManager interface, which is an object responsible for managing and invoking request processor. In other words we have a manager and worker children. If not the controller XML needs changing. How about I'm n

Re: composable RequestProcessor

At 16:33 +0100 6/1/03, Peter A. Pilgrim wrote: For Expresso I too have subclassed the TilesRequestProcessor for our own ExpressoRequestProcessor. Can a module have more than one controller? Not the way it is right now, and I'm not sure why you'd need it. I think if you want to use the approach yo

Re: composable RequestProcessor

David Graham wrote: One thing that bothers me is that RequestProcessor is not an interface which leads to the Tiles situation. If it were an interface, you could implement your one method and delegate the rest to the TilesRequestProcessor or any number of other processors. IMO, RequestProcesso

  1   2   >