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

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: 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

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

>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

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

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

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 multiple discrete int

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

> -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 org.apache

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

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 multiple discrete in

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

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

The controller that I have seen, appear only to subclass one or two methods. In other wards the controllers are specialising certain methods only. Some of these methods are returning an object. Be it an ActionForward or java.lang.String at some point you have to decide which return value should be

RE: composable RequestProcessor

This leads to a proliferation of classes. The standard Java way of dealing with large interfaces it to provide an Adapter class that people can subclass and override the few methods they need. I can see how your worried that we will end up with a truckload of classes - and we certainly will end

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

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

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

DO NOT REPLY [Bug 20417] - Attribute idName not declared for NestedRadioTag

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20265] - Locale missing when constructing a MessageFormat in MessageResources

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20178] - html:img doesn't respect module pagePattern settings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: composable RequestProcessor

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 picked TilesRequestProcess

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

DO NOT REPLY [Bug 20432] New: - Validator returns nulls in JavaScript validation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20433] New: - [PATCH] Add Cocoon plugin URL and description

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20433] - [PATCH] Add Cocoon plugin URL and description

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20434] New: - [PATCH] Adds Struts BSF URL and description

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20434] - [PATCH] Adds Struts BSF URL and description

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Validator Javascript being displayed on the jsp page

My application is using the struts validator (struts 1.1). It has some pages that don't use the validator. Illustration: Page 1 - InitialSearch.jsp (validator) Page 2 - SearchResults.jsp (no validator) When the InitialSearch.jsp page is displayed the first time it displays correctly. But if I n

Re: Validator Javascript being displayed on the jsp page

This sounds like a bug that was fixed some time ago. What version are you using? David From: "Manisha.Datye" <[EMAIL PROTECTED]> Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: Validator Javascript being displayed on the jsp page Da

RE: Validator Javascript being displayed on the jsp page

I am using Struts 1.1. Thanx, Manisha -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 10:23 PM To: [EMAIL PROTECTED] Subject: Re: Validator Javascript being displayed on the jsp page This sounds like a bug that was fixed some time ago. What v

RE: Validator Javascript being displayed on the jsp page

That doesn't really help us. 1.1 has been around for over a year. What version of 1.1 are you using? David I am using Struts 1.1. Thanx, Manisha -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 10:23 PM To: [EMAIL PROTECTED] Subject: Re: Val

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

I am very much in line with you. Where do we go from now? It would be a pity if we let the ideas drain, we discussed here. --- Matthias Andrew Hill wrote: This leads to a proliferation of classes. The standard Java way of dealing with large interfaces it to provide an Adapter class that peopl

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: composable RequestProcessor

> -Original Message- > From: Matthias Bauer [mailto:[EMAIL PROTECTED] > > > I am very much in line with you. Where do we go from now? It > would be a > pity if we let the ideas drain, we discussed here. > > --- Matthias > > > Andrew Hill wrote: > > > > >This leads to a proliferatio

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

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) 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

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

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

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 in

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

Yep. Having a look at the processXXX methods in the RP Id say that most arent really amenable to chaining anyhow. (One likely exception is the processPreprocess() hook, however if chaining is required for this it could perhaps be done by an implementation of its interface 'PreprocessProcessor' that

Re: composable RequestProcessor

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: processForwardConfig, internalModuleRelativeForward, inter

Re: composable RequestProcessor

Thus, it is not only the the processXXX methods that must be redefineable. But what is the consequence? Will we need to end up in something like this? ... I guess the final consequence would be to allow each single method of the request processor to be replaced by