> -----Original Message-----
> From: Christopher Lenz [mailto:[EMAIL PROTECTED]
> Sent: 23 June 2003 11:13
> To: Cactus Developers List
> Subject: Re: cvs commit: jakarta-
> cactus/framework/src/java/share/org/apache/cactus
> AbstractWebServerTestCase.java
> 

[snip]
> 
> Okay, I hope I've read all the threads now, so I'll dare to add my 2
> cents :-)
> 
> I think we are mixing concerns. The WebRequest class is just the user
> API for setting up the HTTP request that will be sent to the
redirector.
> It should not try to be more, and -- more importantly -- it should not
> expose Cactus internals to the user.

Yep, exactly.

> 
> The current design happens to use WebRequest to add the Cactus
> parameters to the request. Nick's addition of the CactusCommand stuff
> has promoted this implicit usage to an actual API, adding a facet to
> WebRequest which should not be there. I.e. WebRequest is being used as
a
> general abstraction for HTTP requests.

agreed

> 
> This is a code smell IMHO. We should now not resort to tricks with
> inheritance or package-private-access to separate the user-API side of
> WebRequest from the internal-API side. Rather, the core should move
away
> from using WebRequest as a general HTTP abstraction facility, possibly
> moving towards more direct usage of the HttpClient API. However, this
is
> not the time for such refactorings!
> 
> I would like to see the CactusCommand stuff reverted to normal use of
> addParameter() etc. Adding an internal RequestDirectives class as a
data
> structure to hold the various parameters/directives would be a nice
idea.

+1

My view is:
- GlobalWebRequest
  - WebRequest: user data
  - DirectivesRequest : internal cactus data

And the HTTP connector uses the GLobalWebRequest. Whether we have a
GlobalWebRequest (the name is badly chosen) or not is not that
important. 

What's important is that the internal cactus classes manipulate the 2
classes and that WebRequest has no link to the cactus implementation.

Thanks
-Vincent

> 
> Hmm, I've gotto run for the train now, maybe continue this later :-P
> 
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to