Internal redirect?

[AF-9]

Hello,

Is there a way to internally redirect to a different controller /
method?


- AF

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[Rod D.]

Hello AF.


AFO wrote:
> Hello,
>
> Is there a way to internally redirect to a different controller /
> method?
>
>
>  
from tg import redirect

Then from within one controller you can redirect to another.

  ...
   redirect('another_controller')

Rodney

> - AF
>
> --
>
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbogears@....
> To unsubscribe from this group, send email to turbogears+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=.
>
>
>
>  

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[Raphael Slinckx-3]

I think that will trigger a 302 redirect, not an internal one.

On Nov 23, 4:36 am, Rodney Haynie <rodney.hay...@...> wrote:

> Hello AF.
>
> AFO wrote:
> > Hello,
>
> > Is there a way to internally redirect to a different controller /
> > method?
>
> from tg import redirect
>
> Then from within one controller you can redirect to another.
>
>   ...
>    redirect('another_controller')
>
> Rodney
>
> > - AF
>
> > --
>
> > You received this message because you are subscribed to the Google Groups "TurboGears" group.
> > To post to this group, send email to turbogears@....
> > To unsubscribe from this group, send email to turbogears+unsubscribe@....
> > For more options, visit this group athttp://groups.google.com/group/turbogears?hl=.

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[AF-9]

On Nov 23, 5:28 am, Raphael Slinckx <rslin...@...> wrote:
> I think that will trigger a 302 redirect, not an internal one.
>

Exactly.... is there any way to do it internally?

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[Diez B. Roggisch]

On Monday 23 November 2009 15:30:45 AFO wrote:
> On Nov 23, 5:28 am, Raphael Slinckx <rslin...@...> wrote:
> > I think that will trigger a 302 redirect, not an internal one.
>
> Exactly.... is there any way to do it internally?

No. I've written such thing as part of my tgext.simpleauth, a
repoze.w*-replacement.

http://bitbucket.org/deets/tgextsimpleauthorization/

It is coneceived as middlewar, and you can perform internal and external
redirects.

However, I would advise in general *against* internal redirects, because you
might mess up the WSGI-environ when doing so.

Diez

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[AF-9]

> > > I think that will trigger a 302 redirect, not an internal one.
>
> > Exactly.... is there any way to do it internally?
>
> No. I've written such thing as part of my tgext.simpleauth, a
> repoze.w*-replacement.
>
> http://bitbucket.org/deets/tgextsimpleauthorization/
>
> It is coneceived as middlewar, and you can perform internal and external
> redirects.
>
> However, I would advise in general *against* internal redirects, because you
> might mess up the WSGI-environ when doing so.
>

How does telling the TG2 dispatch code to simply start processing with
a different exposed() method mess with the WSGI-environ?  (Unless it's
emulating a real 302 that just never get back to the client...?)





--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[Diez B. Roggisch]

On Monday 23 November 2009 18:40:27 AFO wrote:

> > > > I think that will trigger a 302 redirect, not an internal one.
> > >
> > > Exactly.... is there any way to do it internally?
> >
> > No. I've written such thing as part of my tgext.simpleauth, a
> > repoze.w*-replacement.
> >
> > http://bitbucket.org/deets/tgextsimpleauthorization/
> >
> > It is coneceived as middlewar, and you can perform internal and external
> > redirects.
> >
> > However, I would advise in general *against* internal redirects, because
> > you might mess up the WSGI-environ when doing so.
>
> How does telling the TG2 dispatch code to simply start processing with
> a different exposed() method mess with the WSGI-environ?  (Unless it's
> emulating a real 302 that just never get back to the client...?)

The WSGI-stack passes down an environment. This might get modified, for
whatever purposes. E.g. you can alter header-values to force Pylons to
deliver i18n'd messages with a user-defined language instead of browser-based
one. You can stick values in there like identities or other objects.

Now bouncing back a redirect to a specific middlewar that then dispatches
again, this will of course *not* undo changes that have been made before.

This *can* cause havoc. It might be that some middleware makes assumptions
about certain things in the environ that because of this bouncing back and
forth are messed up.

I don't say it has to happen. It *could* happen, and lead to hard to debug
problems because your request-flow gets increasingly complex.

So just using a 302 is the safer alternative, unless you have good reasons not
to do that and are prepared to possibly sanitize your environment.

Diez

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[AF-9]

> > > > > I think that will trigger a 302 redirect, not an internal one.
>
> > > > Exactly.... is there any way to do it internally?
>
> > > No. I've written such thing as part of my tgext.simpleauth, a
> > > repoze.w*-replacement.
>
> > >http://bitbucket.org/deets/tgextsimpleauthorization/
>
> > > It is coneceived as middlewar, and you can perform internal and external
> > > redirects.
>
> > > However, I would advise in general *against* internal redirects, because
> > > you might mess up the WSGI-environ when doing so.
>
> > How does telling the TG2 dispatch code to simply start processing with
> > a different exposed() method mess with the WSGI-environ?  (Unless it's
> > emulating a real 302 that just never get back to the client...?)
>
> The WSGI-stack passes down an environment. This might get modified, for
> whatever purposes. E.g. you can alter header-values to force Pylons to
> deliver i18n'd messages with a user-defined language instead of browser-based
> one. You can stick values in there like identities or other objects.
>
> Now bouncing back a redirect to a specific middlewar that then dispatches
> again, this will of course *not* undo changes that have been made before.
>
> This *can* cause havoc. It might be that some middleware makes assumptions
> about certain things in the environ that because of this bouncing back and
> forth are messed up.
>
> I don't say it has to happen. It *could* happen, and lead to hard to debug
> problems because your request-flow gets increasingly complex.
>
> So just using a 302 is the safer alternative, unless you have good reasons not
> to do that and are prepared to possibly sanitize your environment.
>
> Diez

At the WSGI level I can certainly see the redirect being an issue.

But, I was referring strictly within TG2.   Or, are all TG2 controller
methods actual distinct WSGI entities?




--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=.

[Diez B. Roggisch]

>
> At the WSGI level I can certainly see the redirect being an issue.
>
> But, I was referring strictly within TG2.   Or, are all TG2 controller
> methods actual distinct WSGI entities?

No, but the whole dispatch and everything is based upon the request being a
thin layer over the WSGI-environ.

Diez

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

[AF-9]

On Nov 24, 11:31 am, "Diez B. Roggisch" <de...@...> wrote:
> > At the WSGI level I can certainly see the redirect being an issue.
>
> > But, I was referring strictly within TG2.   Or, are all TG2 controller
> > methods actual distinct WSGI entities?
>
> No, but the whole dispatch and everything is based upon the request being a
> thin layer over the WSGI-environ.
>
>

OH... Ok.

thanks

--

You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@....
To unsubscribe from this group, send email to turbogears+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.