Posted by kev on Wednesday, March 22, 2006
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 public/.
The 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 app/views/ directory.
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 app/views/layouts/ directory.
* 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.xml or 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.
Note that <% or <%= 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 or in PHP).
The public directory
The app/public directory directly links to the root directory of your application. This is where you can place images, stylesheets and javascript. In fact, Rails already creates directories for these purposes at app/public/images, app/public/stylesheets, and app/public/javascripts which are used by the helpers defined by Rails (which I will talk about later).
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.
<title><%= @title || "My default title" %></title>
<%= stylesheet_link_tag 'global' %>
<%= javascript_include_tag 'custom', 'prototype', 'effects' %>
</head>
<body>
<div id="header">
<%= render :partial => 'shared/header' %>
</div>
<div id="content">
<%= yield %>
</div>
<div id="footer">
<%= render :partial => 'shared/footer' %>
</div>
</body>
</html>
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, stylesheet_link_tag and javascript_include_tag. These are both ActionView (the name Rails gives to it’s View part of MVC) helpers. They do what their name says, and generate the html to include javascript files and stylesheets. They automatically handle file extension (.js or .css) and the directory (WEBROOT/javascripts or WEBROOT/stylesheets) for you.
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.
Partials
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 render :partial.
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.
Learning More
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.
No comments:
Post a Comment