cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric SCHAEFFER" <eschaef...@posterconseil.com>
Subject Re: HTTP headers (redirect and so on..)
Date Tue, 01 Feb 2000 05:22:38 GMT

----- Original Message -----
From: Stefano Mazzocchi <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Monday, January 31, 2000 8:17 PM
Subject: Re: HTTP headers (redirect and so on..)


> Eric SCHAEFFER wrote:
> >
> > Youps, sorry. I misunderstood something (+ I thought that if the
document
> > was null in Engine.java, it could raise an NullPointerException or
something
> > like that).
> > I'm confused...
>
> I think that setting the output to null should be discouradged. I
> discussed with Eric before and i think we should have a
> StopProcessingSignal throwable class that can be thrown to signal the
> end of the processing.
>
> But in case SAX is used, you should call closeDocument() and terminate
> that. I think we should leave the return null hack for now and thinking
> about correct SAX handling in the future.

+1

>
> > (But you don't return null, you set the document variable to null in
your
> > XSP page because the populateDocument function doesn't return anything.)
>
> ??

I just wanted to say that, when you request for an XSP page, the XML
document is tranformed in a java file by the XSP engine, and the method
called to have the final output is 'populateDocument' in this class. This
method 'return' void, thus you have to set the 'document' variable to null
and not return null. That's all.
(Not very important, but ...)

>
> > But I've got another problem : XSP pages are compiled and cached in the
> > repository. They can be recovered by their URL. Good.
> > But what if it's my producer that return different XML documents
depending
> > on the context ?
>
> That should _not_ be handled by your producer, but the sitemap should
> call the right producer depending on some rules or some matching class.
>

I put my code there because it's the only 'process' that is in top of each
request. My code performs restriction access and security ckecks. In ASP or
others, if you want to do that, you need to do it in every page. That's
definitively not the good solution. We should be able to do it at the Web
Server level. And if I want to use HttpSession, I need to do it at the
Servlet Engine level. For now, Cocoon is associated only to xml files, but I
would like to 'protect' all my ressources with a unique method (it would be
perfect). I don't really know how to do it...
I haven't tried the sitemap yet. Do I need to install Tomcat ? (I don't
really know what is the 'sitemap', sorry...).

> > I wrote a producer that perform some verifications before reading the
XML
> > file, and redirect the client to another URL when a error occures.
> > As the producers can't write directly in the response object, my
producer
> > return an XML document to perform the redirect. If I return an XSP page,
and
> > if it's already catched, it isn't recompiled and no redirect is
performed...
>
> ? the redirect tells the browser to request another URI which can be
> handled by another XSP. I don't see the problem. Are you talking about
> internal redirection?

Here is a big problem (or mistake). When you write a Web application (or
site), the only thing that the final user sees is the URL of the current
page. Frames have been removed everywhere because it breaks the 'Web logic'
: you always see only one URL, but you can display other pages (you don't
know where you are, you can't bookmark the current page, etc...).
If you do an internal redirect (witch I can do in my producer because it can
choose to return the XML document it want), you also break the 'Web logic'.
I don't want to do an internal redirect, I want a true HTTP redirect.
Internal redirects are good for internal problems and processing...

The problem is that XSP pages are compiled in the repository. If the first
time a page is requested, everything is Ok, then the compiled page is the
'true' page. Now, at the second request, the processor detects an error and
wants to redirect the client to the error page. It then returns an XML
document containing XSP code to perform the redirect. As the page is already
compiled, the Cocoon engine call the cached version, that is the good one.
Do you see what I mean ?

Doing like this is not the good way. I shouldn't have to return an XML
document to do a redirect...

>
> > My question is : why producers can't have access to the response object
?
>
> Because they should not be able to mess with the output stream directly.
> We all agreed that a better Request/Response model should be defined,
> and that producers should have access to _some_ response methods, but
> not all.
>
> Niclas told me he's going to propose a better API for Request and
> Response objects. We should wait for his proposal before dive into this
> more deeply.

Ok.
I will use my old redirect processor until a decision is make.

>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
>
>

_______________________________________

Eric SCHAEFFER
eschaeffer@posterconseil.com

POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059

----------------------------------------------------------------------------
-----------------------------
 Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
_______________________________________



Mime
View raw message