Recently I have been working with file uploads quote a bit in Ruby on Rails. In the past I have struggled through the process of allowing a user to upload a file (whether it be an image or a PDF file) from a web form. Let’s just say that this represents one of those occasions that I am glad to be using Ruby on Rails, due mainly to a nice little plugin called “attachment_fu” by Rick Olson. This is a file upload plugin that makes the process of uploading files from web forms almost trivial, and makes the uploading, resizing, and thumbnailing of uploaded images much, much easier.

Installation is as simple as typing:

(more…)

In the process of developing our new site using Ruby on Rails I have come across quite a few plugins that I thought I would share. Of course, there are an endless number of plugins available for Rails, with many more becoming available every day. In case you are curious, a “plugin” is a set of files that adds functionality to your Rails application. Installation of plugins is very simple, as with most things in Rails. You simple type script/plugin install plugin_name from a command line in your application, and the plugin gets installed for you. So without going into too much detail about what plugins are, let’s take a look at some of the plugins that I have found helpful recently:

will_paginate plugin

Pagination was removed from the Rails 2.0 core code, with the developers opting to move pagination functions to plugins instead. The result is that there are many pagination options to choose from, including code it up yourself if you feel like it. I don’t, and prefer to use this plugin. Simply install the plugin, check out the README file included with it, and you are up and running with paginated pages in no time. A nice, very easy way to display multiple pages of data, and not go too heavy on the database while you are doing it.

(more…)

I realize that I haven’t been posting as much recently, and one of the reasons is that we are getting down to the final build stages of our new website, which should be going live sometime in the next couple of months. Needless to say, and since I am basically the only one working on it, it has been taking up quite a bit of my time. On the plus side, there are lots of things to share. As I have mentioned before, our new site will be built using the Ruby on Rails framework, and I wanted to share my appreciation of Scott Barron’s Acts_As_State_Machine plugin.

This plugin, which for a Rails application can be installed with one simple command, provides an engine for dealing with different “states” of a database record. If you are like me, that might be a little confusing. Basically what it means is that frequently you will have database records that will need to be assigned a certain state, or status. For example, let’s say that you have user records in a database, and that you want to be able to assign certain “states” to users, such as “active” and “suspended”. In the past I have always tackled this with boolean fields in a database, or even an integer field where various numbers represent various states. A “1″ might represent “active”, whereas a zero would represent “inactive”, and so on.

(more…)

As some of you may have noticed since updated your Rails gems to the new 2.0.2 version, there have been some changes to the defaults. The primary one that will stare many people in the face is that rather than defaulting to MySQL as the database application that Rails uses, it now wants to default to using SQLite3. The Rails core team sums up their decision in this post on the Rails blog, which seems to make sense. After all, being opinionated is what Rails is all about.

However, I still use MySQL, and will probably continue to for a while. I know quite a few people that will also probably continue to use MySQL, which means that when we are generating a new Rails application we will need to start telling Rails that we want to change the database application. This is simple enough, as creating a new application is simply a matter of typing this following into the terminal:

rails applicationName

Of course, this will default to SQLite3, so in order to have Rails generate a new application that will interface with MySQL, we simply add a flag to our command, resulting in:

rails -d mysql applicationName

This will generate a new application that uses the MySQL adapter, just like the default used to be. There are quite a few other changes, so I recommend checking out the Rails blog in order to get caught up. Specifically, there is another new default that will not look for updated templates in production mode. Rather, it will cache views in production mode, meaning that when you change templates on the production server you will also need to restart the application server (Mongrel in most cases) in order for Rails to register the changes.

I’m certainly not the first person to put this information out there, but for anyone that has been following this blog for Rails information should be aware that the newest version has been released. Rails 2.0 boasts a series of new features and improvements, most of which appear to me to be under the hood more than right in your face. Most notable to me are the following changes and new features:

1. View template file name changes.
In order to more accurately reflect what Rails is doing, all generators will now use a new naming convention with regards to view templates. In the past a view file might be called something like “articles.rhtml”, which would denote that an HTML view is to be rendered. In an effort to separate out the MIME type and the renderer of the view, the new naming convention will use names such as “articles.html.erb”. In this example, you can see that the file name shows a MIME type of HTML, and that the ERB renderer should be used to render the output. What would previously have been “articles_rss.rxml” would now be called “articles_rss.xml.builder”, telling us that the MIME type will be XML and that Rails will use the Builder renderer to show the view. Older template file names will still work until Rails 3.0 is released, so this one is going to be a phased transition.

(more…)

Just kidding… you can’t. But it’s a good title for a blog post since if you run into the problem that I ran into, you probably searched for that. The reality is that iFrames are a bad idea, and have been for years. The harsher reality is that they are not allowed at all in xHTML 1.0 Strict, meaning that either a browser will not even display it (which is probably the better option) or it is displayed but causes your code to not validate. Usually this never comes up, since we usually just assume that frames are bad and to avoid them.

But what about when you need to upload some images and you want to do it without updating the page? Ajax does not allow for file uploads, so that is not an option. A good example of this is a Wordpress interface when you are creating a new article. In order to allow someone to upload an image for placement in their post, there is an iFrame there to accomodate that. At least in my installation, I wouldn’t be surprised if they have upgraded that part. Either way, I want our editorial staff to be able to upload images when they are composing articles without having to refresh the page (and potentially destroy their edits). An iFrame is not an option since I am taking great care to make sure that this application is XHTML 1.0 strict, and also compliant in the Big Four browsers.

(more…)

There is a Rails plugin that I have been playing with since reading some stuff about it on RailsEnvy that is called acts_as_ferret. It provides the functionality to do full text searches of information in a database, including indexing and such, which is great because searching is extremely complex. I’m not going to spend much time going through how to install the plug-in, as that information is easily available via the link above, and by searching for the plugin. I would, however, like to outline a couple of things that I ran into while exploring this plugin, and some solutions to them.

First thing’s first, what are my goals? In this case I was working on some functionality for our new website (which is going to be super nice!) where I simply wanted to search a couple of models (or database tables) and return the results. More specifically, my application uses a live search form to send search requests via Ajax, and updates the page display to narrow results as a user types in their search query. One additional piece of information is that I only wanted to index certain fields in my models.

(more…)

Well, back to the caching stuff for Rails. The first method I wanted to tackle in this post is the use of cache sweepers to clear cache files for a particular model when it is updated. To use our article example from before, if I made a change to the article model, such as creating a new article, editing an existing article, or deleting an article, I would then need to expire any cached files that display this model data. The reason being that since the model was updated, the cache file no longer reflects the current data in the model.

To clear cache files based on when a model is updated, sweepers are the way to go. Rails cache sweepers simply observe a model, and anytime that it is updated the sweeper jumps into action by expiring any cache files that need to be expired. They are a nice way of ensuring that your caches are up to date simply and easily.

(more…)

Well, we’ve covered various ways to cache content in our Rails application, primarily with the goal of relieving the number of queries to the database. As I mentioned before, the fastest situation is where a request is made for a static page, which the server simply retrieves from the disk and sends to the user’s browser. We can do this with Page Caching in Rails, which if you remember made it so that Rails would copy the output of an entire page to a static HTML file in the public directory of our application. Subsequent requests simply get that static page. Using the following code:

expire_page();

We were able have Rails erase that cache. The next fastest situation is where only Rails gets involved, perhaps doing some simple processing (such as putting templates together) and then spitting out the output. This situation is achieved by action and fragment caching, where Rails is invoked, but we try to avoid database calls that can be slow. While it’s usually not a problem in development, when a web application scales and begins to experience higher traffic with more database records, queries can be slow. We had similar functions for expiring these caches when we wanted to:

(more…)

In my last post, I talked about fragment caching in Rails in terms of caching entire actions from a controller, or what is called Action Caching. Obviously, action caching isn’t always going to work because it again caches the entire output of an action, much like Page Caching. The only difference is that with Action Caching we were able to run before and after filters with Rails to ensure that we could do things like authentication.

However, one of things that we want to accomplish is to be able to cache with more control. For example, let’s say that once a user is logged into our site, we want them to see a list of articles, but also have a personalized message at the top, something like “Welcome Back, Brian”. Or, the content of the page would be adjusted to provide content that is specific to the user’s preferences, meaning that the results of the same action can be different depending on the user that is making the request. In this case, we need to look at something called Fragment Caching.

(more…)