In AWDR it is said that when using ActiveRecord stand-alone (not within rails) the observers have to be "manually" instantiated (not in the environment.rb file). So where should this be done? (inside the Model class?)
You should be able to put them anywhere, and "require" them. Note that a lot of observer-like behavior can be done by implementing callback -- see the "AR Life Cycle" chapter in AWDR.
Also, give me a page number for their point about AR standalone -- I want to double-check what I'm saying.
I'm actually not going to talk about Observers. I will talk about the life cycle callbacks.
The development.log for ccc1 has lots of these scattered through it:
DEPRECATION WARNING: Disabling sessions for a single controller has been deprecated. Sessions are now lazy loaded. So if you don't access them, consider them off. You can still modify the session cookie options with request.session_options.. (called from at /Users/jgn/repos-copies/e168f09/examples/ccc1/app/controllers/application_controller.rb:3)
Not really important -- I'll fix it for ccc2, which will include the controllers and views. The ApplicationController in ccc1 is for an old version of Rails.
These deprecation warnings are useful so that when you go to a new version of Rails, you see in the log stuff you need to fix up for the NEXT version when, typically, stuff that gets a dep warning goes away (and your code breaks).
See if you can add it to http://publications.plugh.org and give me user experience feedback . . . (credentials for this site are in a recent e-mail to the class from me.)
P.S. In that writeup, this line: "In the present times, its hard to imagine a good web application not using Sessions." Very generally, I would disagree with this. My advice is to avoid sessions if you can, and if you must use them, use them very sparingly. I will try to say a word or two about this in this week's or next week's lecture.
You might store it in a cookie (or, better, store a hash of the user id in a cookie; your user table would need to have a column for that hash value).
OR, use the session VERY SPARINGLY. Just storing a user id is cool. A session is always leveraging a cookie, anyway. With a session, you're using an id from the cookie to look up the session data. So you could eliminate the middleman.
In the "no sessions" model, there are typically two things you would want to keep across requests: A user id, and some String representing the user so you can say "logged in as Ron."
Besides the scaling issue, there's also the system management issue. If you can avoid sessions, it's one fewer moving part in a complicated application.
Note that there is one sweet piece of Rails that requires sessions: The Flash. So, typically, Rails apps do use sessions, but as sparingly as possible: And, quite frequently, they will store the entire session object itself in a cookie, which is currently the default for Rails 2.x.
Using the cookie store requires care -- ideally you want it to be encrypted and signed.
In AWDR it is said that when using ActiveRecord stand-alone (not within rails) the observers have to be "manually" instantiated (not in the environment.rb file). So where should this be done? (inside the Model class?)
You should be able to put them anywhere, and "require" them. Note that a lot of observer-like behavior can be done by implementing callback -- see the "AR Life Cycle" chapter in AWDR.
Also, give me a page number for their point about AR standalone -- I want to double-check what I'm saying.
I'm actually not going to talk about Observers. I will talk about the life cycle callbacks.
The development.log for ccc1 has lots of these scattered through it:
DEPRECATION WARNING: Disabling sessions for a single controller has been deprecated. Sessions are now lazy loaded. So if you don't access them, consider them off. You can still modify the session cookie options with request.session_options.. (called from at /Users/jgn/repos-copies/e168f09/examples/ccc1/app/controllers/application_controller.rb:3)
What does this mean, and is it of any importance?
@Ron Newman
Not really important -- I'll fix it for ccc2, which will include the controllers and views. The ApplicationController in ccc1 is for an old version of Rails.
These deprecation warnings are useful so that when you go to a new version of Rails, you see in the log stuff you need to fix up for the NEXT version when, typically, stuff that gets a dep warning goes away (and your code breaks).
I found this to be a very useful top-down approach to Sessions and Cookies in Rails:
http://www.quarkruby.com/2007/10/21/sessions-and-cookies-in-ruby-on-rails
@Gabriel Hase
Nice.
See if you can add it to http://publications.plugh.org and give me user experience feedback . . . (credentials for this site are in a recent e-mail to the class from me.)
@Gabriel Hase
P.S. In that writeup, this line: "In the present times, its hard to imagine a good web application not using Sessions." Very generally, I would disagree with this. My advice is to avoid sessions if you can, and if you must use them, use them very sparingly. I will try to say a word or two about this in this week's or next week's lecture.
Hmm, I'm curious how I would keep a authenticated user logged in without storing a user ID in the session (a technique taught in PHP in CSCI E-75)
@Ron Newman
You might store it in a cookie (or, better, store a hash of the user id in a cookie; your user table would need to have a column for that hash value).
OR, use the session VERY SPARINGLY. Just storing a user id is cool. A session is always leveraging a cookie, anyway. With a session, you're using an id from the cookie to look up the session data. So you could eliminate the middleman.
In the "no sessions" model, there are typically two things you would want to keep across requests: A user id, and some String representing the user so you can say "logged in as Ron."
Read here starting at slide 25: http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches
Besides the scaling issue, there's also the system management issue. If you can avoid sessions, it's one fewer moving part in a complicated application.
Note that there is one sweet piece of Rails that requires sessions: The Flash. So, typically, Rails apps do use sessions, but as sparingly as possible: And, quite frequently, they will store the entire session object itself in a cookie, which is currently the default for Rails 2.x.
Using the cookie store requires care -- ideally you want it to be encrypted and signed.