Ulrich Mayring wrote:
>
> Christopher Painter-Wakefield wrote:
> >
> > I think the point is also well taken that, hey, redirects
> > are a part of the current state of the art
> > in web programming.
>
> Not only that, redirects are part of the HTTP standard. So they should
> be the first thing that is supported by a web app framework and better
> mechanisms could be introduced additionally. But I think where there's a
> standard, it should be possible to use it. I mean, it *is* possible to
> use redirects in the Sitemap and in Actions, but unfortunately not in
> XSP.
Redirects are not possible largely due to the SAX pipeline. Read my other
mails for details.
> This leads me to the question: what else is not possible in XSP? If the
> request object were fully exposed like in Cocoon1, then redirects would
> work. So is the request object not accessible anymore in Cocoon2's XSP?
> What about the session and response object?
The Request and Session objects are wrapped with Cocoon objects--so that
we can have the same application work wether in a Servlet environment, a
Command Line environment, or an Avalon environment. The abstraction allows
you to handle a number of situations. The abstraction is based on the
HttpServlet spec. You can get to the Request, Response, and Session objects
as usual. You may not sendRedirect() from the version you get, or obtain
a reference to the output stream. I think you may already be used to not
getting the output stream in Cocoon 1. The output stream is explicitly
set in Serializers and Readers.
The objects you seek are all in the Map objectModel passed in to your pages.
for XSP, the Request, Context, and Response objects are stored as class
variables. Through them, you can get your Session and Cookie objects as usual.
other than sendRedirect and getting a reference to the output stream, nothing
should be hidden from you.
S/MIME Cryptographic Signature
