I was thinking about having instance variable stored and fetched from
session container automatically before calling an action and after the
action is finished. Using methodology of accessors it would look like:
class MyController < ActionController::Base
persistent_attr :person
def alfa
person = ''John Smith''
# render as usual view alfa.rhtml with anchor link to action beta
end
def beta
render :text => ''Person: '' + person
end
end
This would have scope of hosting controller, but it could be broaden to
other controllers like with
persistent_attr :person,
:scope => [OtherController, AnotherController]
Just thinking little louder...
--
Kamil (aka Gunnie)
Czech Rep.
Kamil Kukura wrote:> I was thinking about having instance variable stored and fetched from > session container automatically before calling an action and after the > action is finished. Using methodology of accessors it would look like: > > class MyController < ActionController::Base > > persistent_attr :person > > def alfa > person = ''John Smith'' > # render as usual view alfa.rhtml with anchor link to action beta > end > > def beta > render :text => ''Person: '' + person > end > > end > > > This would have scope of hosting controller, but it could be broaden > to other controllers like with > > persistent_attr :person, > :scope => [OtherController, AnotherController] > > > Just thinking little louder... >How does this differ from having a before_filter set the variable? -- skaes
Stefan Kaes wrote:> How does this differ from having a before_filter set the variable?before_filter is called before a view is rendered but *after* an action has been called so setting a variable there is just too late. -- Kamil
Is that true? I''ve been using before_filters to fetch data from sessions into controller instance variables for use with other controller methods without any trouble.... On 11/3/05, Kamil Kukura <kamil.kukura-iKbljaP1DMalVyrhU4qvOw@public.gmane.org> wrote:> before_filter is called before a view is rendered but *after* an action > has been called so setting a variable there is just too late.
Kamil Kukura wrote:> Stefan Kaes wrote: > >> How does this differ from having a before_filter set the variable? > > > before_filter is called before a view is rendered but *after* an > action has been called so setting a variable there is just too late. >That''s just plain wrong. before_filters are called before the action is performed. You can even break out of an action using them. after filters are called after the action has been performed. around filters do both. Maybe you schould consult the docs: http://api.rubyonrails.com/classes/ActionController/Filters/ClassMethods.html -- skaes
James Adam wrote:> Is that true? I''ve been using before_filters to fetch data from > sessions into controller instance variables for use with other > controller methods without any trouble....Hmm, I have just tested it and in fact it works, but when I was trying to achieve the same in version 0.13 I had no success. Perhaps I was testing it incorrectly or something has changed in newer version. After all, maybe pre/post processing could be fine grained into chain: before_control --> action --> before_filter --> view --> after_filter --> after_control -- Kamil
On 3.11.2005, at 11.59, Kamil Kukura wrote:> James Adam wrote: >> Is that true? I''ve been using before_filters to fetch data from >> sessions into controller instance variables for use with other >> controller methods without any trouble.... > > Hmm, I have just tested it and in fact it works, but when I was > trying to achieve the same in version 0.13 I had no success. > Perhaps I was testing it incorrectly or something has changed in > newer version. > > After all, maybe pre/post processing could be fine grained into chain: > > before_control --> action --> before_filter --> view > --> after_filter --> after_controlLike Stefan said, your assumption is plain wrong. The filter chain (see [1]) has stayed the same for a while, certainly longer than since 0.13. Why do you want a filter between the action and the view? In fact, the view is parsed _inside_ the action (on the render call) so that doesn''t sound like a very good idea to me. //jarkko [1] http://rails.rubyonrails.com/classes/ActionController/Filters/ ClassMethods.html> > -- > Kamil > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Nov 3, 2005, at 2:59 AM, Kamil Kukura wrote:> James Adam wrote: >> Is that true? I''ve been using before_filters to fetch data from >> sessions into controller instance variables for use with other >> controller methods without any trouble.... > > Hmm, I have just tested it and in fact it works, but when I was > trying to achieve the same in version 0.13 I had no success. > Perhaps I was testing it incorrectly or something has changed in > newer version. > > After all, maybe pre/post processing could be fine grained into chain: > > before_control --> action --> before_filter --> view > --> after_filter --> after_control >This would be a nice addition to the present filter hooks. I would change the naming, however, to be a little more backwards compatible: before_filter --> action --> before_render --> view --> after_filter There''s no need to have an after_render that I can see. AND with regard to your other idea, Kamil, I think it''s a fantastic shortcut to accessing session variables. I would love to see persistent_attr integrated. Do you already have working code? Duane Johnson (canadaduane)
Duane Johnson wrote:> AND with regard to your other idea, Kamil, I think it''s a fantastic > shortcut to accessing session variables. I would love to see > persistent_attr integrated. Do you already have working code?First, apologize for messing things up. I want to work something out during the weekend if I find time for it. Now I''m thinking about keeping session storage small by clearing session variables when different controller from last one is used. That would work until a user will open new window, do some actions by other controller in it and then closes window and gets back to main [origin] window. Maybe clearing session variables on switching to other controller is not good way. -- Kamil
On Nov 4, 2005, at 3:12 AM, Kamil Kukura wrote:> Duane Johnson wrote: >> AND with regard to your other idea, Kamil, I think it''s a >> fantastic shortcut to accessing session variables. I would love >> to see persistent_attr integrated. Do you already have working >> code? > > First, apologize for messing things up. I want to work something out > during the weekend if I find time for it. Now I''m thinking about > keeping session storage small by clearing session variables when > different controller from last one is used. That would work until a > user will open new window, do some actions by other controller in > it and then closes window and gets back to main [origin] window. > Maybe clearing session variables on switching to other controller > is not good way. >How about modifying the url_for helper so that anything declared as persistent_attr gets re-written in the URL string? This could be the best of both worlds. For example: class MyController < ApplicationController persistent_attr :sort_direction def list # the @sort_by instance method is automatically retrieved by a before_filter # created by the persistent_attr call. @my_list = SomeModel.find :all, :sort => ["my_column ?", @sort_direction] end end In my/list.rhtml: <%= link_to "somewhere else", :controller => ''elsewhere'', :action => ''an_action'' %> produces: <a href="/elsewhere/an_action?sort_direction=ASC">somewhere else</a> And any links *back* to MyController would, of course, propagate the sort_direction so that we get it back when we need it. Duane Johnson (canadaduane)