Rails - Apr 2010 - newb's quick question on session variable vs. params in 'pretty' urls

Hi,

Is there a compelling reason to prefer reliance on the params hash vs.
the same info stored in a session hash? So, for example, params[:id] @loan vs.
session[:loan_id] = @loan.id? It matters because I can make
prettier urls if I store certain uniquely identifying model attributes
as session variables.

The drawback I can think of in preferring session variables to the
params hash is that a user cannot be guaranteed to recover via the
same url the same model instance under the session-preferred approach,
because the session variable may have changed.

Thanks for any comment,

Grar

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Apr 15, 2010, at 2:37 PM, Grary wrote:
> 
> Hi,
> 
> Is there a compelling reason to prefer reliance on the params hash vs.
> the same info stored in a session hash? So, for example, params[:id] >
@loan vs. session[:loan_id] = @loan.id? It matters because I can make
> prettier urls if I store certain uniquely identifying model attributes
> as session variables.
> 
> The drawback I can think of in preferring session variables to the
> params hash is that a user cannot be guaranteed to recover via the
> same url the same model instance under the session-preferred approach,
> because the session variable may have changed.
> 
> Thanks for any comment,
> 
> Grar

Server farms are one reason, but with cookie-based session store, it''s
not that big a deal. The other reason that comes to mind is Web crawling.
Relying on session state often defeats Web crawlers, although that does not seem
like it''s relevant to the example you gave. Why can''t you make
load_id part of the URL using routing?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Steve,

I''m persisting a ''transitional'' object through a few
views, spawning
descendants from it and then deleting the parent object. In this case,
then, it doesn''t seem to make sense to publicize a reference to the
transitional object in a url because the referenced object will not be
persisted indefinitely -- indeed its creation should be silent to the
user.

Grar

On Apr 16, 2:07 pm, steve ross
<cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Apr 15, 2010, at 2:37 PM, Grary wrote:
>
>
>
>
>
> > Hi,
>
> > Is there a compelling reason to prefer reliance on the params hash vs.
> > the same info stored in a session hash? So, for example, params[:id]
> > @loan vs. session[:loan_id] = @loan.id? It matters because I can make
> > prettier urls if I store certain uniquely identifying model attributes
> > as session variables.
>
> > The drawback I can think of in preferring session variables to the
> > params hash is that a user cannot be guaranteed to recover via the
> > same url the same model instance under the session-preferred approach,
> > because the session variable may have changed.
>
> > Thanks for any comment,
>
> >Grar
>
> Server farms are one reason, but with cookie-based session store,
it''s not that big a deal. The other reason that comes to mind is Web
crawling. Relying on session state often defeats Web crawlers, although that
does not seem like it''s relevant to the example you gave. Why
can''t you make load_id part of the URL using routing?
>
> --
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
> For more options, visit this group
athttp://groups.google.com/group/rubyonrails-talk?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

This is, then, a perfect use for session.

On Apr 17, 2010, at 7:15 AM, Grary wrote:
> 
> Steve,
> 
> I''m persisting a ''transitional'' object through a
few views, spawning
> descendants from it and then deleting the parent object. In this case,
> then, it doesn''t seem to make sense to publicize a reference to
the
> transitional object in a url because the referenced object will not be
> persisted indefinitely -- indeed its creation should be silent to the
> user.
> 
> Grar
> 
> On Apr 16, 2:07 pm, steve ross
<cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Apr 15, 2010, at 2:37 PM, Grary wrote:
>> 
>> 
>> 
>> 
>> 
>>> Hi,
>> 
>>> Is there a compelling reason to prefer reliance on the params hash
vs.
>>> the same info stored in a session hash? So, for example,
params[:id] >>> @loan vs. session[:loan_id] = @loan.id? It matters
because I can make
>>> prettier urls if I store certain uniquely identifying model
attributes
>>> as session variables.
>> 
>>> The drawback I can think of in preferring session variables to the
>>> params hash is that a user cannot be guaranteed to recover via the
>>> same url the same model instance under the session-preferred
approach,
>>> because the session variable may have changed.
>> 
>>> Thanks for any comment,
>> 
>>> Grar
>> 
>> Server farms are one reason, but with cookie-based session store,
it''s not that big a deal. The other reason that comes to mind is Web
crawling. Relying on session state often defeats Web crawlers, although that
does not seem like it''s relevant to the example you gave. Why
can''t you make load_id part of the URL using routing?
>> 
>> --
>> You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Talk" group.
>> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit this group
athttp://groups.google.com/group/rubyonrails-talk?hl=en.


-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.