Hello, I know this is going to be very simple but I am new enough to not have it very clear. If I wanted to have values/constants and code available in all parts of the application (views, controllers and models), where should I put them? And a bonus question, I have noticed that session values are not available in the models. Is there a reason for that or maybe I am not smart enough to figure it out? Thank you. Pepe --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> I know this is going to be very simple but I am new enough to not have > it very clear. > > If I wanted to have values/constants and code available in all parts > of the application (views, controllers and models), where should I put > them?Actually, that''s not such a simple question, because it depends a lot on the data you want to provide. Typically this type of information is provided in the session hash. In fact that''s one purpose of the session hash. In an object oriented applications global variables are generally considered evil and should be avoided. Constants are already available anywhere in your application through the namespace of the class. If you had: class MyClass MY_CONSTANT = "Whatever" end You would access that constant with MyClass::MY_CONSTANT. Notice the namespace operator "::" used.> And a bonus question, I have noticed that session values are not > available in the models. Is there a reason for that or maybe I am not > smart enough to figure it out?This is by design. It is, technically, a violation of MVC to make session variables available in model objects. This would create a tight coupling between the model and the view/controller. MVC is designed to prevent that. Model objects should be reusable apart from their view/controller. Depending on a session variable in your model would break that reusability. At least that''s the theory. In practice there are ways around this, but I wouldn''t personally recommend them unless you have no other choice. Generally speaking, if you are feeling the need to access session data in a model, chances are you''re doing something wrong. A proper encapsulated and decoupled solution should be sought in those cases. pepe wrote:> Hello, > > I know this is going to be very simple but I am new enough to not have > it very clear. > > If I wanted to have values/constants and code available in all parts > of the application (views, controllers and models), where should I put > them? > > And a bonus question, I have noticed that session values are not > available in the models. Is there a reason for that or maybe I am not > smart enough to figure it out? > > Thank you. > > Pepe-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks a lot, Robert. The explanation about the MVC design makes absolute sense. The way I am going around the session values is by passing variables to the methods I need to execute in the models. I was curious as of why the session values were not available there. I already knew about the MyClass::MY_CONSTANT way of accessing the values but I wasn''t sure if there was another, "simpler" way by which those values can be accessed. If there is no "simpler" way, where should I put my class with my constant definitions then and would I need to require the class in my controller and models? Thanks a lot. Pepe On Aug 27, 11:54 am, Robert Walker <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > I know this is going to be very simple but I am new enough to not have > > it very clear. > > > If I wanted to have values/constants and code available in all parts > > of the application (views, controllers and models), where should I put > > them? > > Actually, that''s not such a simple question, because it depends a lot on > the data you want to provide. Typically this type of information is > provided in the session hash. In fact that''s one purpose of the session > hash. > > In an object oriented applications global variables are generally > considered evil and should be avoided. > > Constants are already available anywhere in your application through the > namespace of the class. > > If you had: > > class MyClass > MY_CONSTANT = "Whatever" > end > > You would access that constant with MyClass::MY_CONSTANT. Notice the > namespace operator "::" used. > > > And a bonus question, I have noticed that session values are not > > available in the models. Is there a reason for that or maybe I am not > > smart enough to figure it out? > > This is by design. It is, technically, a violation of MVC to make > session variables available in model objects. This would create a tight > coupling between the model and the view/controller. MVC is designed to > prevent that. > > Model objects should be reusable apart from their view/controller. > Depending on a session variable in your model would break that > reusability. At least that''s the theory. In practice there are ways > around this, but I wouldn''t personally recommend them unless you have no > other choice. > > Generally speaking, if you are feeling the need to access session data > in a model, chances are you''re doing something wrong. A proper > encapsulated and decoupled solution should be sought in those cases. > > > > pepe wrote: > > Hello, > > > I know this is going to be very simple but I am new enough to not have > > it very clear. > > > If I wanted to have values/constants and code available in all parts > > of the application (views, controllers and models), where should I put > > them? > > > And a bonus question, I have noticed that session values are not > > available in the models. Is there a reason for that or maybe I am not > > smart enough to figure it out? > > > Thank you. > > > Pepe > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@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 -~----------~----~----~----~------~----~------~--~---
Quoting pepe <Pepe-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org>:> > Thanks a lot, Robert. > > The explanation about the MVC design makes absolute sense. The way I > am going around the session values is by passing variables to the > methods I need to execute in the models. I was curious as of why the > session values were not available there. > > I already knew about the MyClass::MY_CONSTANT way of accessing the > values but I wasn''t sure if there was another, "simpler" way by which > those values can be accessed. If there is no "simpler" way, where > should I put my class with my constant definitions then and would I > need to require the class in my controller and models? >If they truly are application wide, put them in a Ruby file in the config/initializers/ directory. This feature was introduced in 2.X, IIRC. Where X is in the range 0 to 1, IDRW (I Don''t Recall Which). Or in prior versions at the bottom of config/environment.rb HTH, Jeffrey --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks a lot Jeffrey. Pepe On Aug 28, 11:05 am, "Jeffrey L. Taylor" <r...-f/t7CGFWhwGcvWdFBKKxig@public.gmane.org> wrote:> Quoting pepe <P...-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org>: > > > > > Thanks a lot, Robert. > > > The explanation about the MVC design makes absolute sense. The way I > > am going around the session values is by passing variables to the > > methods I need to execute in the models. I was curious as of why the > > session values were not available there. > > > I already knew about the MyClass::MY_CONSTANT way of accessing the > > values but I wasn''t sure if there was another, "simpler" way by which > > those values can be accessed. If there is no "simpler" way, where > > should I put my class with my constant definitions then and would I > > need to require the class in my controller and models? > > If they truly are application wide, put them in a Ruby file in the > config/initializers/ directory. This feature was introduced in 2.X, IIRC. > Where X is in the range 0 to 1, IDRW (I Don''t Recall Which). > > Or in prior versions at the bottom of config/environment.rb > > HTH, > Jeffrey--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@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 -~----------~----~----~----~------~----~------~--~---