Posts from codefluency...
I’ve had a few requests for the syndication URL for [just] the Rails Views series … so here it is:
http://codefluency.com/xml/rss20/tag/railsviews/feed.xmlI’ll be continuing to write new entries for the series; the feedback has been very positive—and there’s definitely plenty of material left to cover!
One of the key “sneaky” aspects of developing AJAX applications in Rails is the use of the :with option, available in about all of the AJAX-related methods. This option is used to dynamically generate a query string (meaning params, once it hits the server) using Javascript. This allows you to roll your own parameters, freestyle, with DOM lookups.
It’s pretty neat stuff (especially when playing with observe_field and observe_form), but it can be pretty tricky. Here’s a couple things to look out for.
So, today my fresh, dead-tree copy of Ruby for Rails arrived.
As the technical proofreader for this excellent book by David A. Black, I’ve obviously spent some time reading it in depth … but seeing the final result sitting on my table is still pretty impressive.
For those of you that don’t know, David has been a leading member of the Ruby community since long before Rails was a twinkle in DHH’s eye (who, by the way, wrote the foreword for the book). He’s one of the directors of Ruby Central, the parent organization for the official Ruby and Rails conferences, and knows Ruby.
In the book David did some great work explaining the language in depth and delving into Rails from a Ruby perspective; if you’re a Ruby programmer by way of being a Rails developer, this book is the one to pick up to help you understand the underlying language.
A few articles back, I mentioned how useful helpers that take blocks can be within your views.
I thought I’d give a little example, giving a helper I find pretty useful in my own projects.
Here’s the code, which I’ll explain in a moment:
def link_to_section(name, html_opts={}, &block)
section_id = name.underscore.gsub(/\s+/,'_')
link_id = section_id + '_link'
# Link
concat(link_to_function(name,update_page{|page|
page[section_id].show
page[link_id].hide
}, html_opts.update(:id=>link_id)), block.binding)
# Hidden section
concat(tag('div', {:id=>section_id, :style=>'display:none;'},true),block.binding)
yield update_page{|page|
page[section_id].hide
page[link_id].show
}
concat('What this makes possible is stuff like:
<% link_to_section("View Details") do |closer| %>
Details
Some detailed text detailing detailed details.
<%= link_to_function("Hide Details",closer) %>
<% end %>What’s going on here is actually pretty simple. The helper generates a link (with the label you’ve given) to show a a hidden div and hide itself. The block given to the helper is what will end up inside that div, and it’s yielded the snippet of javascript necessary to switch back (so that you can use that snippet wherever you’d like).
Keep in mind assumes you’ll only have one link per page with the same label … if you think that won’t be the case, you’ll probably want ensure the ids generated inside the helper are unique; using object_id would be a simple way to do so.
One of the things you do when dealing with views that will be modified via AJAX is set DOM IDs on elements you’ll want to modify or remove.
This is especially true if you’re creating elements for a set of ActiveRecord objects. Perhaps you have a JournalEntry model and give a series of list items ids like:
<% @entries.each do |entry| %>
-
<%= entry.body %>
<% end %>
Isn’t this a tedious activity to do by hand? It’s not only frightfully dull to do in any volume, but it also increases the likelihood you’ll make a mistake, especially since you’ll need to remember what naming scheme you’re using in any RJS actions you develop to make use of the ids.
There’s a better way, and by “better” I mean lazier and generally more satisfying.
One of the techniques we’ve been using at work to develop our Rails application is based on the Rails plugin system.
There are several UI components of our application that are a mix of Controller and View pieces. Rather than have each of these strung out across the Rails framework, we package them in plugins.
Even though we’re not distributing these, they’re large enough and used often enough in our application for the separate packaging to really pay off.
Helpers that take blocks are a core element of the new approach to developing views for Rails. What are they, and why should they be used? To put it plainly, block helpers are a bit of Ruby magic that will save you time and no little amount of sanity.
Let’s use a simple example. Imagine a situation where you are wrapping chunks of markups in a div with the same CSS class. This is happening in various templates.
The old approach would either be to just type in the wrapping div manually every time, or maybe have two partials; one rendered before, and the other after the chunk of markup.
This is the type of “insert header here,” and “insert footer here” PHP-like clunkiness I try to avoid.
Block helpers make this inelegant kludge unnecessary. They allow you insert “common” markup before and after the block, and also to yield whatever object you’d like to the block so it can be used—like form_for’s builders.
Here’s a diagram, just for the hell of it.
Now, let’s continue by giving a simple example.
In the beginning (or nearly so), we had form_tag and end_form_tag. Now, these were still better than typing and , and trying to throw in form attributes, but they really didn’t even begin to use the full power of what Ruby (and ERB) had to offer.
A while back, form_for (and it’s sexy friend remote_form_for) came on the scene, but a lot of people haven’t noticed. These are cleaner, more elegant, and more flexible ways of making both regular and remote forms, and you should be using them.
Ok, here’s the deal. I’m about to commit blasphemy. I’m going to recommend you put view-related code in the controller.
Wait a second. What about the whole MVC thing… never the twain shall meet, right? What kind of madness is this??!? (ducks lightning bolt)
Put down the pitchforks and torches, dammit, and listen.
One of the least used techniques I’ve seen used in Rails applications—and one I think is not only very elegant, but also saves time—is the use of update_page directly in link_to_function.
Why aren’t more people using this? I just don’t get it. A lot of work went into RJS … so why not use it?