So the problem solving continues, each day a new challenge in this framework. However, someday I will make ruby.sing any tune I need and I'll be glad I fought it out.
Using the Model, View, Controller framework you are sometimes presented with a not so straightforward problem. My problem presented itself in the form of a stylesheet. That innocent .css file that makes everything on this page look the way it does. I had the style sheet, but I thought it would be nice to easily change the style sheet based on the method. That way if I decided method a should look different then method b (both in the same controller) then all I should have to do is change a variable. My first solution was quite simple:
I could add an instance variable to each method defining what stylesheet to use!
This approach is flawed, and without much more than an initial test I soon scrapped the idea. If I had went that route I would be forced into one particular problem:
Each method would have to have the variable. If I forgot one, I would be in trouble!
Thats when I decided to put the style sheet variable into some initial method that would load with each action. This would allow me to have a default for all the methods, and just override the default in any method I needed. So how do I do that? At first I wasnt sure... I tried just putting the @style_sheet variable outside of any method (of course that didn't work). After a few minutes I remembered something I had seen elsewhere. Define an initialize method and stick the instance variable in there. Just like:
def initialize
@style_sheet = "sapient.css"
end
(And a snippet from my 'user' layout)
<link href="/stylesheets/<%= @style_sheet %>" rel="stylesheet" type="text/css">
That done it! I now have all my methods using the same style sheet... and if I need to I can attach a different one just by changing the value of the instance variable in the method.
The next event of considerable mention (and in fact it took quite a bit of my time) is handling sessions. I have a basic CMS on this site, and I decided that it was a good time to add authentication to tighten up security. And what goes hand in hand with authentication on a web application? Sessions!
In the enjoyable read "Agile Web Development with Rails" I came across a good deal about sessions. The two options that I decided to choose between were- file held sessions, and database held sessions. The former stores session data in files in a temp folder, the latter stores the session data as rows in a table you setup for your application (conveniently named sessions). For scalability you would want to choose database session management (it is far easier to move a database to a seperate server than it is to use a network drive for session storage, in my opinion). So I decided - what the heck - why not go all out and do database sessions. Enter the SQL that created the sessions table:
CREATE TABLE `sessions` (
`id` int(11) NOT NULL auto_increment,
`sessid` varchar(255) NOT NULL default '',
`data` text NOT NULL,
`updated_at` datetime default NULL,
PRIMARY KEY (`id`),
KEY `session_index` (`sessid`)
);
Whichever method you chose be aware of one thing:
"People are often surprised that Ruby's session handler, which Rails uses, doesn't do automated housekeeping" - From the aforementioned book (pg 464)
Thats right! This obviously cannot be a feature of Ruby (if it is I would be shocked, but perhaps I am not seeing the complete picture). So be sure to implement some script or cron job to remove old session files or clear the old session records (otherwise trouble will eventually visit you).
To enable database session management I had to make a swift change in the config/environment.rb file in my rails project. Adding a line exactly like the following tells active record to store sessions for you in the database:
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:database_manager] = CGI::Session::ActiveRecordStore
That prepares you for session storing, next thing to do is write some authentication methods and test them out. This however will have to wait until part 2 of this post, look for it to be available tomorrow. I'll discuss a basic authentication setup (with code snippets for it to work) as well as anything else I run across between now and then.