cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Date Wed, 18 Apr 2001 13:54:53 GMT
> Colin Britton wrote:
> > I also cleaned up the environment by removing some of the 
> > methods in the
> > Request und Response objects, mainly (--and please don't kill 
> > me now--)
> > the sendRedirect method and some other methods for 
> > manipulating the response
> > output. (For the first initial test, I only commented the 
> > sendRedirect etc out...)
> > 
> 
> OK, so now you have removed it, I think it would be good for someone to
> show, document and provide examples of the *correct* way to do
> redirects. From the other Donald Ball's other email ([c2] problem with
> actions) it was clearly not intuative to him how to do it from an action
> - so the rest of us are in real trouble.
> 
> I think that removing this without showing how people are meant to work
> is like chopping off someones legs. 
Hm, nice comparison...

I think Giacomo showed in the last days during the discussions some examples
how to live without the redirecting. 
My idea behind removing it, is the opposite approach: See if we can live without
it and solve all upcoming problems.

The sitemap is the only place for the workflow of your application, thus
redirects belong to the sitemap and not to the XML (XSP) level. That is
only content - and a redirect is not content at all. So we have here again
SoC: sitemap for workflow and the pipeline-processing for content.

> 
> A good scenario to make clear the usage for xsp would be for a user
> login, lets say we have a form which checks a user name and password in
> a database, this form is processed by an xsp (I know you could do it in
> actions but a lot of people do this in XSP with C1). The result is is
> the person is allowed in they get redirected to welcome.xsp or if false
> get redirected to login_failed.xsp. You may have a better example in
> which case great.
> 
No this example is absolutely perfect - we do exactly this many times,
and guess how: with Actions. XSP was the solution for C1 as there weren't
any actions, now we have the better (?) solution: Actions.
So what you would do, is instead of creating an XSP page which does the
evaluation of the form, you would simply write an action which does
the same, and then you could use the following sitemap fragment:

<map:match pattern="test-page">
<map:act type="UserValidationAction"> <!-- returns a map if the user is allowed -->
  <map:redirect-to uri="welcome.xsp"/>
</map:act>
<map:redirect-to uri="login_failed.xsp"/>
</map:match>

PS: Please keep in mind that we can - if necessary - always reinclude the 
    sendRedirect. This is a try if we can really follow SoC.


Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message