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 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.

URL Breakdown

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.

Layout Diagram

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.

app/views/layouts/application.rhtml
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <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>

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, 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.

Posted in , ,  | 22 comments

Comments

  1. Avatar Tracey said about 2 hours later:

    Nice write-up Kevin.

  2. Avatar Chris said about 5 hours later:

    This is great. As a designer myself, I think its great to see some articles focusing on design for the Internet. With all buzz going on right now, I’d like to see more of it directed towards real information for designers (rather than articles making fun of “Web 2.0” design).

    BTW, I just noticed you’re in San Diego. Us too! Always excited to see a fellow rails-enthusiast who’s local.

  3. Avatar Kevin Clark said about 6 hours later:

    Hey Chris, Good to hear from another local! Anyway, if you’re interested in more designer focused Rails information (or just write ups for the right brained person) you might want to check out Amy Hoy’s blog at http://slash7.com.

  4. Avatar Brad said about 14 hours later:

    Kevin, It’s great to see that you are from San Diego, as am I. I find rails very interesting compared to my normal mode of writing web-apps which is in Coldfusion. I have been thinking about moving from Coldfusion to rails because of its very quick development environment. Although getting a good understanding of the rails environment still alludes me. I’ve parsed Pragmatic’s “Agile webdev with Rails” but I am still questioning how I should go about designing my clients’ web-apps. Go with Rails and use Backbase (now that it is free) for my apps’ visual presence or Scriptaculous (which seems to work not quite as smoothly as backbase) or should I stick with Coldfusion and ready myself for Flex 2.0 which shouldn’t be too far out now. So many questions and not many opinions. I am a big fan of Coldfusion and its rock-solidness, but maybe it is time to move to true MVC with rails. What do you think?

  5. Avatar Kevin Clark said about 22 hours later:

    Brad, These days I do all of my development (freelance and at Mingle) in Rails, so that’s the decision I’ve made. I think it is faster, cleaner, more maintainable and in general makes me a happier coder.

    I haven’t used Backbase of CF before (I came from a PHP/ASP background, and before that C/C++/Java) but as far as scriptaculous goes, I’ve found it quite excellent. It integrates very well with Rails (which has helpers for it built in) and because it is open source it is easy to get bugs fixed when they occur. Additionally, because it is bundled with Rails, you have a good percentage of the Rails population using it and avaliable for support.

  6. Avatar Nick Dominguez said 1 day later:

    Kevin: Great post, as a designer working with developers building web apps on Rails, it’s nice to see someone write an article for designers about rails.

    Brad: If you’re on the fence about Rails, I would tell you to invest some more time with ROR and I think you’ll be sold once everything clicks.

  7. Avatar iTech said 1 day later:

    Thanks for the wonderful introduction, sort of puts it into a good perspective for me. Glad that some people actually worry about those below them and share their knowledge. I’m hoping to design a blog for http://itech.webwarp.net and don’t quite know whether it would be suitable to just install an engine or do it all yourself. Thanks for the information.

  8. Avatar Jay Levitt said 1 day later:

    Could you explain why yield is better than @content_for_layout? I’ve seen this asserted twice on the Rails list but without any particular reasoning. I think that yield may make more sense to us as developers, but that @content_for_layout seems like a much easier construct for designers to grasp.

  9. Avatar Travis Schmeisser said 1 day later:

    Great write up! I’m a desinger trying to learn this and it helps a ton. Thanks a million!

  10. Avatar Kevin Clark said 1 day later:

    Jay, yield is prefered because it allows the core developers to change what happens in the backend more easily than an accessible instance variable (which is what @content_for_layout is). They’re looking for long term maintainability, and yield is better to that end. yield is also more Ruby-like.

  11. Avatar Hunter said 1 day later:

    I’m starting RoR and this is a great introduction. I am also in San Diego. Maybe we should get a users group going? There is a Ruby group, but I don’t think it’s taken off yet. http://sandiegorug.org/

    Let me know! Thanks!

  12. Avatar Kevin Clark said 1 day later:

    Hunter: YES. The RUG was started up just before RubyConf and we met once or twice after, but it’s since fallen into the nothingness. We should revive it. Shoot me an email at kevin dot clark at gmail dot com.

  13. Avatar Rod said 2 days later:

    Thanks for this guide. I am a long time designer that is just starting to work with Rails. It’s nice to see such a simple breakdown with conceptual terms that are a little easier for me to quickly grasp.

  14. Avatar random8r said 2 days later:

    I expected the design to be a bit better, considering.

  15. Avatar Adam Keys said 2 days later:

    Thanks Kevin, this looks like a terrific resource. It serendipitously appeared on my radar today, the same day I was going to give a presentation at Refresh Dallas from the same angle.

    My presentation is called Down the Rabbit Hole and focuses on how Rails makes the life of a front-end architect easier and happier. I hope those who’ve read your piece here find it helpful!

  16. Avatar Amy Hoy said 2 days later:

    This is not the place for it, but oh well. Urgh. `yield` s so much less friendlier, and less sensible, than `@content_for_layout` :(

    Changing it is a wrong decision, if you ask me. Yield may be more Ruby-like in theory, but it’s less human-like in this case. Besides, we only expect to see `yield` inside a method which takes a block, not a template.

  17. Avatar Kevin Clark said 2 days later:

    Amy: The layout does take a block—the controller code. I guess it might make sense to alias yield to a more friendly method name… submit a ticket, email the list, and propose a patch!

  18. Avatar andré camargo said 5 days later:

    HTMLers use Dreamweaver(DW) or other WYSIWYG tool to turn PNGs into code.

    Saying that, have anyone some thoughts to share about RoR x DW?

  19. Avatar andré camargo said 5 days later:

    hey… sorry for 3 same comments!! but, that submit button isn’t updating the screen or maybe I am crazy…

  20. Avatar Kevin Clark said 5 days later:

    andre: Yeah, my blog is doing weird things lately. I’ve removed the extra posts.

  21. Avatar Matt said 6 days later:

    Great post. I’m also a designer turned Rails developer, and I’m still learning as I go with Big Cartel.

  22. Avatar Mark Priestap said 37 days later:

    Thanks for the write up! Good stuff. You might want to delete all the comment spam. icky.

Comments are disabled