'c' variable between redirects

On Fri, Aug 24, 2007 at 02:33:07PM +0200, Tomasz Nazar
wrote:
> Whatever variable attached to 'c', it is available in
the template when
> rendered via 'render_response('x.tmpl')'.
> 
> I often however use redirects
'h.redirect_to(another_action)' to reuse
> controller's code. And the 'c'-attached variables are
not present in the
> redirected template.

Correct. A redirect issues a "Location:" header to
be sent to the
browser and that concludes the current HTTP communication.
The browser
will then start a new HTTP request with the new location.

> As I understand 'c' is always reset before any
controller's action - what is
> not fun for me, as in my app one "user"
request/click is often 2 (or more)
> Pylons controllers' actions, hence http redirects..

Without knowing your application I dare say that this sounds
like you
are using redirect_to in the wrong places. If the
application is
supposed to do multiple things when a user does a certain
HTTP request
then why can't one controller's action do that alone?

> What other options instead of putting variables to http
session does one have
> for passing variables through redirects?

The "session" dictionary.

 Christoph


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discussgooglegroups.com
To unsubscribe from this group, send email to
pylons-discuss-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

>> As I understand 'c' is always reset before any
controller's action  
>> - what is
>> not fun for me, as in my app one "user"
request/click is often 2  
>> (or more)
>> Pylons controllers' actions, hence http
redirects..
>
> Without knowing your application I dare say that this
sounds like you
> are using redirect_to in the wrong places. If the
application is
> supposed to do multiple things when a user does a
certain HTTP request
> then why can't one controller's action do that alone?

Actually, I was in such a situation not too long ago, so I'm
curious  
what the best solution actually is.
The situation itself is as follows:
- user edits form
- submit triggers controller+action.
   I use the same action when posting as when asking for the
form,  
differentiating between POST and GET requests.
- If the POST data does not validate, the rest of the action
is  
executed (having set a c.errors variable), which leads
again
   to the form, but this time with errors indicated. The
user can now  
correct these.
- If the POST data validates, I redirect (to prevent the
'reload post  
data?' question) to the form again, which then executes the
GET part.  
This is done so that the user can edit more if he/she wants.
Perhaps  
this is where I go wrong, but I feel it makes sense in my
case. To  
indicate things have changed, some text on the top of the
webpage  
says 'your data have been updated; you can chance more below
if you  
like'. This text appears if a global variable is set
(g.something),  
which is set just before the redirection. I immediately
remove the  
'something' attribute after doing this (actually, before
rendering,  
but having set c.something = g.something), so that next time
the user  
(re)loads the form webpage, the message disappears.

So perhaps, the last redirect should go to a different
webpage?  
Should that page then have a link 'please click here if you
want to  
change things further'. And one would still like to inform
the user  
that 'your data have been updated', so there's still some
need of  
passing a variable (a simple boolean flag) between
redirects.

>> What other options instead of putting variables to
http session  
>> does one have
>> for passing variables through redirects?
> The "session" dictionary.

As mentioned, I'm using the g variable (removing the
attribute when  
not needed), not session. Which one would be better? Is g
perhaps  
tied to the application, ie if multiple users use it, they
all use  
the same g variable, but session is still
(browser/ip-address) user- 
dependent? Sorry, I'm still a newbie, so I'm not t0o clear
on this.

Cheers,

   Evert



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discussgooglegroups.com
To unsubscribe from this group, send email to
pylons-discuss-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Evert Rol wrote:
> As mentioned, I'm using the g variable (removing the
attribute when  
> not needed), not session. Which one would be better? Is
g perhaps  
> tied to the application, ie if multiple users use it,
they all use  
> the same g variable, but session is still
(browser/ip-address) user- 
> dependent? Sorry, I'm still a newbie, so I'm not t0o
clear on this.

You definitely don't want to use g, which is truly
application-global.
That means separate threads see the same g, and certainly
separate
requests even if they come from different users.

Sessions are tied to the user, which means (roughly) that
regardless of
threads you'll get the correct information about the user.

Everything else you're doing sounds quite reasonable and
clean and nice
for the user, so if you just switch to sessions you'll be
quite
reasonable and clean and nice *and* safe. 

-Peter


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discussgooglegroups.com
To unsubscribe from this group, send email to
pylons-discuss-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---