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:
snip
I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls
-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
than processing a validation request.
Formed like
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
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
-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.
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
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
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
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 public mutator
it to the actions 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 arguments
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
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
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
[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 Ted just wrote
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 request chain looks like this:
process=processLocale,processContent,processNoCache,processPr
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
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
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
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
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
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
pitfalls 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 Validator we
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)
. 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
snip
I'm not sure why you shouldn't open it up all
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
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
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 each of these cases, the effect
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 applications.
In each of these cases
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.
-
, it
still 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't
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
processing goes through
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 Validator, I'd
probably commit it.
One
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
by somehow defining
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
that can provide the necessary 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
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
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:
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
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
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, would
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]
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 struts
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
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:
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
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: composable RequestProcessor
Let's take
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 8:54 AM
To: Struts Developers List
Subject: RE: composable RequestProcessor
snip
At this point, I think the main goal is to come up with a decent name
for an interface which RequestProcessor could implement
/snip
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
dynamic duo would stay but
could be implemented as filters.
/ramble-on
-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:[EMAIL PROTECTED]
Sent
-Original Message-
ramble-on
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
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
-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 manager and
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
-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. This
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();
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've
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
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
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 FooRequestProcessor implements RequestProcessorInterface
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
-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.
If you are saying
import
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 +
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 interface should be easy
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
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 +
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 controllers that I have seem only subclass one or two methods
(for those who 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
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
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
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
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
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
:41
To: [EMAIL 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
-
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
to
implement all the hooks in the RP.
It doesnt
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
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
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
,
or are there drawbacks 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 problem
snip
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
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
snip
This driving request processor
.
-Original Message-
From: Matthias Bauer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 June 2003 18:10
To: Struts Developers List
Subject: Re: composable RequestProcessor
snip
This driving request processor who selects the instances of the sub
request processors should be the one who keeps
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,
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
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
manager
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
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
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 or
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. Pilgrim wrote
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
ControllerConfig and using bean
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
-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 would
very much in favour with a more composable RequestProcessor.
However, I totally agree with David, that it is sufficient to provide a
RequestProcessor interface, instead of choosing the configuration file
approach.
But I don't see a reason why this needs to be deferred until Struts 2.0.
Why can't
;-)
Ok, I will do that next week or so.
--- Matthias
Ted Husted wrote:
Matthias Bauer wrote:
Sounds good. Would you take care of the enhancement ticket, Ted?
Nope. =:0)
You and Joe brought it up, so you or Joe should post the ticket. (We
call that community-building =:)
RequestProcessing?
Andrew Harris
On 30 May 2003 at 7:39, David Graham wrote:
In the 1.x series, we could do something like declare a
RequestProcessorInterface, have the existing concrete classes implement
that, and then change the underlying code to use interface
instead, and
avoid any
That doesn't fit well with method parameter semantics because it's not a
noun. You can't say, I'm passing a RequestProcessing to myMethod.
David
From: Andrew Harris [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: composable
the whole country sectioned off, you can't make a
move without a form.
e.
David Graham [EMAIL PROTECTED]
05/30/2003 09:40 AM
Please respond to Struts Developers List
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
cc:
Subject:Re: composable RequestProcessor
Developers List [EMAIL PROTECTED]
Subject: Re: composable RequestProcessor
Date: Fri, 30 May 2003 17:37:59 +0100
RequestProcessing?
Andrew Harris
On 30 May 2003 at 7:39, David Graham wrote:
In the 1.x series, we could do something like declare a
RequestProcessorInterface, have
A good place to post these suggestions would be the wikiPage:
http://nagoya.apache.org/wiki/apachewiki.cgi?RequestProcessor
-Ted.
Kris Schneider wrote:
RequestHandler?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
% satisified with.
Thus, I am very much in favour with a more composable RequestProcessor.
However, I totally agree with David, that it is sufficient to provide a
RequestProcessor interface, instead of choosing the configuration file
approach.
But I don't see a reason why this needs to be deferred
and the TilesRequestProcessor. In order not to
duplicate any logic, I needed to come up with a class hierarchy I am not
100% satisified with.
Thus, I am very much in favour with a more composable RequestProcessor.
However, I totally agree with David, that it is sufficient to provide a
RequestProcessor
1 - 100 of 105 matches
Mail list logo
