cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: RequestDispatcher & engine.java
Date Thu, 03 Feb 2000 18:13:12 GMT
On Thu, 3 Feb 2000, Mike Engelhart wrote:

> Donald Ball wrote:
> 
> > +1 from me, I'll go ahead and patch this since no one seems to have been
> > bothered by it yet and it works for me on apache-jserv.
> > 
> > - donald
> Wait!  don't patch this as it only works for static page dispatches. If you
> try this;
> 
> <xsp:logic>
>     RequestDispatcher rd =
> request.getRequestDispatcher("anotherxsp.xsp.xml");
>     rd.forward(request, response);
>     // document = null;
>      // return;
> </xsp:logic>
> 
> The half processed originating page shows up after the dispatched page in
> your browser.  REmoving the comments from the above code causes null pointer
> exceptions (sometimes) and other extraneous errors.  Do not patch!!!! :-)

Unpatched. The entire example doesn't work in my environment since I'm
still in JSDK-2.0 land, but I believe you. It doesn't seem like it ought
to have caused errors like you're describing, though - I'll have to delve
deeper into the code.

> Here's my feelings about this.
> I love XSP for generating dynamic content.  For embedding business logic or
> handling servlet type activities it either doesn't work at all or is not
> logical.  I think the XSP engine is too far down in the processing chain to
> reliably handle things like RequestDispatcher's.  A RequestDispatcher is
> designed to wrap a servlet not a Producer of a Processor of a Servlet (even
> though it says it can wrap anything, the API doesn't say what you have to do
> to get it to wrap other objects).  Just yesterday I began writing code using
> Servlets to do the minimal business logic (database lookups, etc.) and stuff
> data into the request object which I then forward to an XSP page, much like
> you do in the MVC design with JSP/Servlets/JavaBeans.  The bonus is that you
> get to seperate content/style completely by having the XSP pages do any
> remaining data manipulation (e.g., iterating through a result set). This
> method of processing works a thousand times better, is significantly faster
> and easier to handle then using strictly Cocoon for development.  Even
> though I heard it a million times from Stefano and others it took a while
> for me to sort out the other noise and realize that Cocoon is a "publishing
> framework", not a development tool.  At least not as of yet and maybe it
> never will be.  Either way it's amazing for publishing web pages, etc. but
> sucks for developing applications.

That sounds like a very nice way to handle 'web application' development.
What sort of caveats do you run into when calling cocoon this way?

- donald


Mime
View raw message