Russell Gold wrote:
> 
> At 06:54 PM 7/2/2001 +0100, Jari Worsley wrote:
> >Russell Gold wrote:
> > >
> > > At 06:07 PM 6/29/2001 +0100, Jari Worsley wrote:
> > > >- by making HttpWebResponse public, you can give it nonsense for the
> > > >target and URL (1st and 2nd params), then give it the HttpURLConnection,
> > > >and get back an HttpWebResponse object, allowing calls like getText(),
> > > >getForms(), etc...
> > >
> > > Or we can specialize it to make a CactusWebResponse - it would be cleaner
> > > and shouldn't take a lot of work.
> >
> >yes you could, although at first glance I would only need
> >HttpWebResponse to be declared a public class, and the constructor
> >either public, or at least protected so it can be overridden from
> >outside the package. Is there any reason the class and constructor are
> >declared as they are rather than public?
> 
> Umm, yes - the class is pretty much coupled to the WebConversation class
> and explicitly assumes that you are loading it from a URLConnection.  We
> may be talking at cross purposes here, and I may have misunderstood some of
> the Cactus architecture, but I see no reason ever to instantiate
> HttpWebResponse from anywhere except WebConversation.

I think we are talking at cross purposes somehow.

My point is, that using cactus, I already have a URLConnection instance,
and I would like to use the html handling abilities that you have built
into HttpWebResponse on the URLConnection I _already_ have.

When a test is executed, at the end of the test on the client I have a
URLConnection available, with the results of a JSP or a servlet call in
the stream. Rather than just using String and text handling, I would
like to be able to get at the "structure" in the stream to see what html
has been returned.


And why should WebResponse and WebRequest be so tightly coupled to
WebConversation? The constructor for a HttpWebResponse is invoked like:

        return new HttpWebResponse( request.getTarget(),
request.getURL(), connection );

in the WebConversation.newResponse method.
In theory why should WebResponse be limited to use just with unit tests
and just with HttpUnit and the webrequest and webconversation classes? 
If public you could just as easily construct a well formed WebResponse
just as a webConversation does by calling:
e.g
// open up a connection to http://jakarta.apache.org/index.html using
some other means then
HttpWebResponse response = new HttpWebResponse("some target", 
                                        new 
java.net.URL("http://jakarta.apache.org/index.html";), 
                                        connection);
// where connection has already been set up.
Then use the WebResponse to look at the structure of index.html.


Jari
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd

Reply via email to