Shakin’ My Money Maker

I just can’t get enough of the “new and improved” Black Crowes lineup featuring my favorite living guitarist, Luther Dickinson (of the North Mississippi All-Stars).

My TBC concert goals for the year 2008 are a little ambitious, but here’s the plan (asterisks indicate shows that I have actually attended or already have bought tickets for):

3/2 — Starland Ballroom, Sayreville, NJ*
6/27 — Hershey Park, Hershey, PA (opening for the Dave Matthews Band)*
7/5 — Charlottesville Pavilion, Charlottesville, VA*
8/3 — Wolf Trap, Vienna, VA*
9/10 — Van Duzer Theater, Arcata, CA
9/12 — Wells Fargo Center, Santa Rosa, CA
9/14 — Civic Auditorium, Santa Cruz, CA
9/17 — The Greek Theater, Los Angeles, CA
9/19 — Santa Barbara Bowl, Santa Barbara, CA
10/7 — The National, Richmond, VA
10/8 — The National, Richmond, VA
10/10 — Borgata, Atlantic City, NJ
10/27 — Hammerstein Ballroom, New York, NY
10/28 — Hammerstein Ballroom, New York, NY
12/15 — The Fillmore, San Francisco, CA
12/18 — The Fillmore, San Francisco, CA
12/19 — The Fillmore, San Francisco, CA
12/20 — The Fillmore, San Francisco, CA

Rock on!

Chris Bucchere Speaking at the NovaRUG on June 18th, 2008

Calling all local Rubyists! I’m speaking about modular page design in Ruby on Rails at tomorrow night’s NovaRUG. The title of my talk is “To Portal or Not to Portal: How to Build DRY, Truly Modular Mashups in Rails.”

The meat of my talk is going to come from these two recent blog posts:

Modular Page Assembly in Rails (Part 1)
Modular Page Assembly in Rails (Part 2)

I’ll be followed by Arild Shirazi of FGM giving a presentation entitled “CSS for Developers.”

Get all the details here.

P.S.: Free pizza!

Modular Page Assembly in Rails (Part 2)

In Part 1, I explained how you can develop clean, DRY and encapsulated MVC code that allows for completely modular page assembly in Ruby on Rails.

In this follow up post, I explain how you can use a combination of layouts and content_for to apply title bars and consistent styles to your page components (or modules or portlets, or whatever you want to call them).

The code here is easy to follow and it pretty much speaks for itself. It consists of two layouts (which I called aggregate and snippet), a sample controller and two sample views. Let’s start with the controller for one page in your site that, say, aggregates a couple of modular page components together to show a nice view of company information.

Controller code (app/controllers/company_controller.rb):

def index
  render :action => 'index', :layout => 'aggregate'  

This controller simply delegates the rendering of the page to the index.html.erb view and tells Rails to use a layout called aggregate.

Now let’s inspect the view.

View code (app/views/company/index.html.erb):

<% content_for :left do %>
 <%= embed_action :controller => 'company', :action => 'company_list' %>
 <%= embed_action :controller => 'feed', :action => 'feed' %>
<% end %>

<% content_for :center do %>
 <%= embed_action :controller => 'company', :action => 'detail' %>
<% end %>

<% content_for :right do %>
 <%= embed_action :controller => 'home', :action => 'sponsors' %>
<% end %>

This view defines three content regions, with the end goal being to create a page with three columns of “portlets.” The left column contains two portlets: a list of all companies (company_list) and a news feed (feed). The center column contains a company detail portlet and the right column contains a portlet with information about sponsors. (Note that the portlets come from three different functional areas of the site, so they’re decomp’d appropriately into three different controllers.)

Now, let’s take a look at some layout magic.

Here’s the aggregate layout (app/views/layouts/aggregate.html.erb):

<table class="main" cellspacing="0" cellpadding="0">
      <td id="column-left" class="column" valign="top">
        <div id="region-left" class="region"><%= yield :left %></div>
      <td id="column-center" class="column" valign="top">
        <div id="region-center" class="region"><%= yield :center %></div>    
      <td id="column-right" class="column" valign="top">
        <div id="region-right" class="region"><%= yield :right %></div>

I chose a table (yes, I still use tables) with three divs in it, one for each region of modules, but you could use pure divs with floating layouts or any other approach.

The three content regions, left, center and right, match up with the three content sections defined in the index view above using content_for. In case this isn’t obvious, when the layout encounters a page-level definition of a content region in the view, it renders it. If there is no definition for a particular region, the containing column will just collapse on itself, which is the behavior we want.

This is a slight digression, but note how I used CSS classes to identify the columns and regions in a general way (using classes) and a specific way (using ids). This allows me to style the whole module-carrying region with CSS using table.main as my selector, all the columns using table.main td.column as my selector or all the regions using table.main td.column div.region as my selector. I can also pick and choose different specifc areas (e.g. table.main td.column#column-right) and define their style attributes using CSS. As you’ll see in a minute, I can write CSS selectors to say if module A is in the left column, apply style X but if module A is in the center or right column, apply style Y. Pretty cool.

Now, let’s explore the module layout. (Note that I’ve been calling page snippets portlets, modules or components, pretty much interchangeably. I think this illustrates that it doesn’t make a difference what we call ’em — e.g. portlets vs. gadgets — the concept is fundamentally clear and fundamentally the same.)

Module layout (app/views/layouts/snippet.html.erb):

<div id="<%= yield :id %>"><%= yield :id %>" class="snippet-container">
  <div class="snippet-title"><%= yield :title %></div>
  <div class="snippet-body"><%= yield :body %></div>

This layout expects three more content regions to be defined in the view: id, title and body. Here are the matching content regions from one sample view (for sponsors) — for brevity’s sake, I didn’t include all the views.

Sample module view (app/views/home/sponsors.html.erb):

<% content_for :id do %>sponsors<% end %>

<% content_for :title do %>Our Sponsors<% end %> 

<% content_for :body do %>
Please visit the sites of our wonderful sponsors!
<% end %>

Now, because of some nicely-placed classes and ids, I can once again use CSS selectors to give a common look-and-feel to all portlet containers (div.snippet-container), portlet titles (div.snippet-title) and to portlet bodies (div.snippet-body). Of course, if I want to diverge from the main look-and-feel, I can call out specific portlets: div.snippet-body#sponsors.

If I really want to get fancy, I can use CSS selectors to select, say, the sponsor portlet, but only when it’s running in the right column: table.main td.column-right div.snippet-container#sponsors.

So, in summary, using layouts, content_for and some crafty CSS, I can create a page of modules that can be styled generically or specifically. Combine this approach with what I described in Part 1, and you can “portal-ize” your Rails applications without using a portal!

Was this useful to you? If so, please leave a comment.

Nominate Chris Bucchere for an Oracle OpenWorld Session

oowI’ve presented at seven Plumtree Odysseys, one BEA World and two BEA Participates. Help keep the streak alive by voting up my Oracle OpenWorld presentation!

Here’s what people had to say about my P08 preso this year. . .

Q5: What did you like most about the session?

  • The ppt presentation style!
  • Straight and to the point, dives right into it. Chris did a fantastic job!
  • very nice to hear how they put this together
  • amazing and inspiring
  • great session; should be one of the first sessions provided.

Q6: What could we do better next year?

  • bring this guy back (again)

The Social Collective Debuts at RubyNation

We’re very pleased to announce that, together with the organizers of RubyNation, we debuted our social application “The Social Collective” today as a means for RubyNation conference attendees and other Rubyists to meet and interact with their peers.

This is a very similar codebase to what we deployed at BEA Participate in May, but without ALI or ALBPM. These BEA (now Oracle) products provided a great, scalable and flexible architecture, but we didn’t feel it was a good use of our resources (i.e. $$$s) to continue to use these products and we didn’t want to pass this cost on to RubyNation, which, BTW, is only charging $175 for two jam-packed days of Ruby awesomeness.

So, for those of you who have been following all this social goodness coming from bdg, there are now two distinct versions of The Social Collective: one that uses BEA/Oracle products and one that does not. This affects pricing (obviously), so if you’re interested in either, please contact us to find out more.

And in the meantime, if you’re as gung ho about Ruby as we are, sign up for an account and help us grow the Ruby community here in DC and beyond!

Modular Page Assembly in Rails (Part 1)

Recently I was faced with an interesting problem: I wanted to create a modular, portal-like page layout natively in Ruby on Rails without using another layer in the architecture like SiteMesh or ALUI. Java has some pretty mature frameworks for this, like Tapestry, but I found the Ruby on Rails world to be severely lacking in this arena.

I started with Rails 2.0 and the best I could come up with at first brush was to create a html.erb page comprised of several partials. Each partial would basically resemble a “portlet.” This works fine, but with one showstopping pitfall — you can’t call controller logic when you call render :partial. That means in order for each page component (or portlet, if you like) to maintain its modularity, you would have to either 1) put all the logic in the partial view (which violates MVC) or 2) repeat all the logic for each component in the controller for every page (which violates DRY).

If that’s not sinking in, let me illustrate with an example. Let’s say you have two modular compontents. One displays the word “foo” and the other “bar”, which are each contained in page-level variables @foo and @bar, respectively. You want to layout a page containing both the “foo” and the “bar” portlets, so you make two partials.

“foo” partial (app/views/test/_foo.html.erb):

<[email protected]%>

“bar” partial (app/views/test/_bar.html.erb):

<[email protected]%>

Now, you make an aggregate page to pull the two partials together.

aggregate page (app/views/test/aggregate.html.erb):

<%=render :partial => 'foo' %>
<%=render :partial => 'bar' %>

You want the resulting output to say “foo bar” but of course it will just throw an error unless you either embed the logic in the view (anti-MVC) or supply some controller logic (anti-DRY):

embedded logic in the view (app/views/test/_foo.html.erb):

<[email protected] = 'foo'%>
<[email protected]%>

embedded logic in the view (app/views/test/_bar.html.erb):

<[email protected] = 'bar'%>
<[email protected]%>

— OR —

controller logic (app/controllers/test_controller.rb):

def aggregate
 @foo = 'foo'
 @bar = 'bar'

Neither solution is optimal. Obviously, in this simple example, it doesn’t look too bad. But if you have hundreds of lines of controller logic, you certainly don’t want to dump that in the partial. At the same time, you don’t want to repeat it in every controller that calls the partial — this is supposed to be modular, right?

What a calamity.

I did some research on this and even read a ten-page whitepaper that left me with no viable solution, but my research did confirm that lots of other people were experiencing the same problem.

So, back to the drawing board. What I needed was a way to completely modularize each partial along with its controller logic, so that it could be reused in the context of any aggregate page without violating MVC or DRY. Enter the embed_action plugin.

This plugin simply allows you to call invoke a modular bit of code in a controller and render its view, but not in a vacuum like render :partial. With it, I could easily put controller logic where it belongs and be guaranteed that no matter where I invoked the “portlet,” it would always render correctly.

Here’s the “foo bar” example, implemented with embed_action.

“foo” controller (app/controllers/foo_controller.rb):

def _foo
 @foo = 'foo' #this logic belongs here

“bar” controller (app/controllers/bar_controller.rb):

def _bar
 @bar = 'bar' #this logic belongs here

aggregate view (app/views/test/aggregate.html.erb):

<%= embed_action :controller => 'foo', :action => '_foo' %>
<%= embed_action :controller => 'bar', :action => '_bar' %>

That’s it! Note that there is no logic in the aggregate controller — that’s not where it belongs. Instead, the foo and bar logic has been modularized/encapsulated in the foo and bar controllers, respectively, where the logic does belong. Now you can reuse the foo and bar partials anywhere, because they’re 100% modular.

Thanks to embed_action, I was finally able to create a completely modular page (and site) design, with very little effort on my part.

In a follow-up post (Part 2), I’ll explain how you can create really nice-looking portlets using everything above plus layouts and content_for.

This Just In — BEA Participate Social App Stats

I find this a little hard to believe, but the numbers don’t lie. We had a whopping 75,000 page views the week of the conference!

That’s more than 100 page views per registered attendee. This chart was from our hottest day, Tuesday, 5/13.

5-13-08(3)Thanks to everyone for using our application. I think we may be on to something here!