Rails for Designers
Posted by kev Tue, 21 Mar 2006 21:57:00 GMT
Finals are done! In celebration, I’ve finished my guide to Rails for designers.
This is for designers who are going to be working with Rails and is intended to give them a good starting point to jump into work with a Rails developer. This is all introductory material. As such, I cover some basics (MVC, locations of files) and move from there to a code example and more advanced topics (partials, ActionView helpers).
Update: If there are other things people think I should cover, feel free to leave comments and I’ll do a follow up article.
Update #2: If you liked the article, digg it!
Update #Again: Marcel Molina (Jr) of the core team notes that
yield is prefered to
@content_for_layout when creating layouts, so I’ve updated my examples.
Views and ‘MVC’
MVC stands for “Model, View, Controller” and is a way to separate what the user sees from what happens behind the scenes.
View: The front-end
View is the section which controls what things look like when they render. What this means for you, the designer, is that you don’t have to fiddle through large blocks of programming logic which get in the way of your markup.
Controller: Programming logic
Controllers are where the actual processing code goes. This is where the variables that might be used in the view (
@which @usually @look @like @this) will be set.
Model: Business logic and the database
The model deals with database and business logic and should never touch the front end.
Your friends, the views and public directories
One of the great things about Rails development is that you always know where something belongs. For designers, your code belongs either in
app/views or in
views directory and dissecting URLs
The basic form of an URL in *Rails is
http://yourhost/controller/action/id. The action corresponds to what view you will be rendering by default in the
So, for example, let’s say that you’re working on a social networking site and you’ve got an URL which looks like
http://www.example.com/friends/show/1. This breaks down to the
app/views/friends directory and the **
show.rhtml file inside of it.
We’ll go over what happens in an rhtml file shortly, but first I’d like to cover the
* If this is not the case, it is because your developer is using something called Routes. Just ask them where the file you’re looking for is located in this instance.
** Again, this might be
show.rjs or something else if your developer is doing something special. Ask them about it if this is the case.
Layouts: Templates in disguise
Basically, layouts are templates. If you think about what happens in a basic site, you’ve got a header, footer and content somewhere in the center. The content comes from your view and all the surrounding stuff that might be page dependent (but can probably be reused) is part of the layout.
By default, a layout named the same as the controller is used. In our example above, the controller is
friends, so a file
app/views/layouts/friends.rhtml will be used for any URL like
http://my.host/friends/anything. Additionally, if you create a
app/views/layouts/application.rhtml file, it will be used by default if there isn’t a file named the same as the controller.
Do note that your developer can tell the view to render a template different from the default any time he wishes, so if you don’t want to be restricted to one layout per
app/views/ subdirectory or controller you can create multiple layouts and the developer can explicitly define which is used.
Ok, so how do I get my view code to render in layouts?
Wherever you’d like the code from your view to go, place this bit of code
<%= yield %>. You might also see
<%= @content_for_layout %>, which does the same thing.
<%= starts Embedded Ruby (ERb) code and
%> ends it. The difference between the two is that
<%= outputs the result of what happens inside the ERb tags (just like
<?= in PHP).
RHTML: Not so scary, really
So far we haven’t looked at much code. For this topic, I really think you need to see what we’ve been talking about.
If we scan
application.rhtml, we see the basic (very basic) structure of an html document. A few elements may not be familiar.
Variables and giving your developer options
From top to bottom, the first thing that is out of place is the title tag. There are ERb tags present which outputs a result, and inside the tags it says
@title || "My default title". Recognize that
@title is a variable (like $title in PHP). If the ERb code only contained
@title then the value of
@title would be printed out. The one difference here is the
|| character. This means OR and effectively how the line reads in English is “print a title if there is one otherwise print ‘My Default Title’”. Doing this allows your developer to choose whether to define their own title or to use the default. If you need to get more complex than that, you should check with your developer first.
Tags to make your life easier
The next thing which isn’t normal html is two ERb tags,
link_to, the hyperlink’s smarter brother
Because designers generally won’t be working with controllers and actions (which is programming logic), you usually won’t be using the
link_to helper in it’s regular form of
link_to 'My link', :controller => 'something', :action => 'something_else', but you should be aware that it creates a hyperlink. You might use
link_to to link to static URLs like
link_to 'My link', '/my_link.html' or to named routes which look like
link_to 'Login!', login_url. Named Routes are a special case, and your developer should tell you if they are being used. For more information, see the api entry.
Applying attributes to Rails tags
There are many helpers in Rails which can output html for you. Most of these take options to modify attributes for each tag. You should see the Rails API for further details, and the Learning More section at the end of this article about how to navigate the API page.
Let’s get back to the code example. Inside the header div things get a little more complicated. Here something called a partial is being rendered.
Think of partials as snippets of code that you’ll want to reuse. If you’re writing a user information div on a forum, you don’t want to have to format each individually. If you have the contents of a shopping cart print in several places, you don’t want to have to write the formatting and code in each place. Partials handle this. To do this, write code as you would in a view but place it in a file prefixed with a “_” and then use
With our user information example, we might place the file
_user_information.rhtml which contains all the code that needs to be rendered for user information in the
app/views/users directory. Then, when we want to use that code in another view, you just use
<= render :partial => 'users/user_information' %>.
Using partials means you only have to edit code once. Everywhere the partial is used will be automatically updated when you make a change.
Effectively yours, Scriptaculous
If you’re not aware of the Scriptaculous library, you should take a look. It is a clean effects library which integrates well with Rails. Using Scriptaculous deserves a full article so I won’t cover usage here.
The Rails API holds all the documentation for the Ruby on Rails framework. As a designer, you will be most interested in ActionView (the name Rails gives for its View codebase). The API site is a bit ugly, but if you look at the left section in the middle frame and find links starting with ActionView you’ll find a wealth of helpers to make writing html easier. Familiarizing yourself with these and being able to find out what the helpers do will make you a better suited Rails designer, even if you choose not to use the helpers all of the time or at all.