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):

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

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

<%@bar = '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.

Twitter down again?

twitter-down-againWith the amount of downtime that twitter experiences, it makes me wonder whether or not Ruby on Rails is a viable alternative to PHP, Java, etc.

Is it the platform (RoR) or is it just bad code from Twitter? Or something else entirely?

Why I. . . .

whyiA couple weeks ago I teamed up with college buddy, recent Kellogg grad and former PayPal/eBay product manager Chris Gregory to design and write a fun little Facebook application called WhyI.

He did the design and product management, my wife Allison did the logo design and I wrote the code. After a few weeks of hacking in Ruby on Rails (using RFacebook) and many hours of Skyping between Chris and Chris, I’m very pleased to announce that we’re done and the application is live on Facebook!

You can use the app to share five-word WhyI “taglines” about your passions on your profile. You can also ask other people to create taglines by asking them “Why do you?” questions.

If you have any questions or feedback on the application, please comment here or send a note to [email protected].

Firebug in IE — No Joke!

I realize it’s close to April Fools’ Day, but this is not a joke: you can actually use Firebug in IE. Well, sort of. Joe Hewitt, the author of every developer’s favorite Firefox extension, has created a Javascript file that you can drop into your web pages and, voila, you get the debug console. And it works in IE. I realize this isn’t quite as good as the full blown Firebug, but it’s sure a lot better than the alternative:

<script>// <![CDATA[ alert('this sucks'); // ]]></script>

Say hello world to comet

A couple of weekends ago I inflicted upon myself a quest to discover what all the buzz was about regarding Comet. What I discovered is that there is quite a bit of code out there to help you get started but the documentation around that code, and about Comet in general, is severely lacking. All I really wanted to find was a Comet-based Hello World, which as any developer knows, is the cornerstone of any programming language or methodology.

Since I couldn’t find one on Google, I ascertained that no Hello World exists for Comet and therefore I took it upon myself to write one.

For those of you who are new to Comet, the first thing you should do is read Alex Russell’s seminal blog post on the topic. At its core, Comet is really just a message bus for browser clients. In one browser, you can subscribe to a message and in another you can publish a message. When a message gets published, every browser that’s subscribed (almost) instantaneously receives it.

What? I thought clients (browsers) had to initiate communication per the HTTP spec. How does this work?

Under the covers, Comet implementations use a little-known feature of some web server implementations called continuations (or hanging gets). I won’t go into details here, but at a high level, a continuation initiates from the browser (as all HTTP requests must do) and then, when it’s received by the server, the thread handling it basically goes to sleep until it gets a message or times out. When it times out, it wakes up and sends a response back to the browser asking for a new request. When the thread on the server receives a message, it wakes up and sends the message payload sent back to the browser (which also implies that it’s time to send a new request). Via this mechanism, HTTP is more or less “inverted” so that the server is essentially messaging the client instead of vice-versa.

A few questions immediately pop into mind, so let’s just deal with them right now:

Why is this better than Ajax alone?

It boils down to latency and users’ tolerance for it. In the worst case, traditional web applications force entire page refreshes. Ajax applications are a little better, because they can refresh smaller parts of a page in response to users’ actions, but the upshot is that the users are still waiting for responses, right? A Comet-driven application has essentially removed the user from the picture. Instead of the user asking for fresh data, the server just sends it along as soon as it changes, given the application more of a “realtime” feel and removing virtually all perceived latency.

So are we back to client server again?

Sort of. Comet gives you the benefit of server-to-client messaging without the deployment issues associated with fat clients.

Can’t applets do this?

Of course they can. But who wants to download an applet when some lightweight Javascript will do the trick?

Why the name Comet?

Well, clearly it’s a pun on Ajax. But it’s not the only name for this sort of technology. There’s something out there called pushlets which claims to do the same thing as Comet, but which didn’t seem to catch on, I guess.

Back to the whole point of this post: my hello world. I pieced this example together using and a recent version of Tomcat that into which I dropped the relevant parts of Jetty to provide support for continuations.

It’s finally time to say “hello world” to my hello world.

First off, download one of the more recent dojo builds that contains support for Drop dojo.js on your Java-based web/application server. (I used Tomcat, but you can use JBoss, Jetty, Weblogic, Websphere or any other web server with support for servlets.) Add this page in the root of your application:

<script src="js/dojo.js" type="text/javascript"></script>
<script type="text/javascript">//<![CDATA[
  cometd.init({}, "cometd");
  cometd.subscribe("/hello/world", false, "publishHandler");
  publishHandler = function(msg) { alert(; }
// ]]></script>
<input type="button" value="Click Me!" />

Without a cometd-enabled web server behind it, the above page does absolutely nothing.

So, to make this work, I needed to find a Java-based web/application server with support for continuations. I’m sure there are many ways to skin this cat, but I picked Jetty. You can get Jetty source and binaries if you’d like to follow along. Since all of our customers who embrace open source are lightyears more comfortable with Tomcat than they are with any other open source web/application server (ahem . . . Jetty), I decided to embed Jetty in Tomcat rather than run everything on Jetty alone. It’s all just Java, right?

Here I ran into a few snags. The maven build file for Jetty didn’t work for me, so I dropped everything in org.mortbay.cometd and org.mortbay.cometd.filter into my Eclipse project and just integrated it with the ant build.xml I was already using to build my web application. Here’s the relevant portion of my build.xml:

<javac srcdir="${srcdir}" destdir="${classdir}" debug="true" debuglevel="lines,vars,source">
<pathelement location="${jetty.home}/lib/jetty-util-6.0.1.jar"/>
<pathelement location="${jetty.home}/lib/servlet-api-2.5-6.0.1.jar"/>

Once Jetty was essentially hacked into Tomcat, the rest was smooth sailing. I just wrote a JSP that dropped a “goodbye world” message onto the same old queue that I used in the last example, but I did so using server-side code. Here’s the JSP:

<%@page import="org.mortbay.cometd.*"%>
<%@page import="java.util.*"%>
Bayeux b = (Bayeux)getServletContext().getAttribute(CometdServlet.ORG_MORTBAY_BAYEUX);
Channel c = b.getChannel("/hello/world");
Map message = new HashMap();
message.put("test", "goodbye world");
c.publish(message, b.newClient());

This page does not produce any output of its own; rather, it just drops the “goodbye world” message on the queue. When you hit this page in a browser, any other browser listening to the /hello/world queue will get the message. The above JSP, along with the dojo page you created in the first step, should be enough to wire together two different flavors of Comet messaging: browser to server to browser and just plain old server to browser.

I’m curious 1) if this was helpful and 2) if you’d like to share what you’re doing with Comet with me (and please don’t say cleaning your kitchen).

Everyone likes a friendly URL

As part of our BEA World strategy for this year, we’re revamping our corporate web site, You should expect an unveiling in the upcoming weeks.

While there will be some revised and some additional content, this is primarily an infrastructure upgrade, including moving to more powerful virtual hosts and upgrading the backend from ASP to ASP.NET (yes, I know, it’s about time).

One of things that really bugs me about ASP and ASP.NET is the failure to include built-in support for friendly URLs. By friendly I mean something that doesn’t end in .asp, .htm, .aspx or some other extension and naturally also doesn’t have a querystring (?foo=bar&boo=moo . . . etc.). For example, is a lot more friendly than and definitely more friendly than something like

Java provides a nice facility for this in the form of servlet mappings. Since a lot of people are using MVC these days, you are probably going to set up servlet mappings anyway. Here’s an example from a sample web.xml file:



But what about ASP or ASP.NET? No one cares about ASP any more, so I didn’t bother to research that. But for .NET, I came up with a simple and elegant solution to the friendly URL problem. All you need to do is add the following code (or something like it) to your Global.asax.cs file:

protected void Application_BeginRequest(Object sender, EventArgs e)
 if (!Request.RawUrl.EndsWith("htm") &&
     !Request.RawUrl.EndsWith("css") &&
     !Request.RawUrl.EndsWith("ico") &&
     !Request.RawUrl.EndsWith("jpg") &&
     !Request.RawUrl.EndsWith("js") &&
   if ("".Equals(Request.RawUrl) || "/".Equals(Request.RawUrl))
     Context.Server.Transfer(Request.RawUrl + ".aspx");

You’ll note that I forward requests to the corresponding aspx page, as long as the request isn’t for static content (images, css, etc.).

Of course you also need to do two things:

  1. Configure an .aspx page for every friendly URL you want resolved
  2. Add a wildcard mapping in IIS for * (files without extensions) to the ISAPI filter

The process for #2 is a little involved. It’s also different for IIS 5 (XP) and IIS 6 (2003). I don’t feel like posting screen shots right now, but if anyone wants to give this a trial run and can’t figure out how to do #2, just e-mail me and I’ll walk you through it.

I just came up with this a couple of hours ago and I haven’t put it through much testing, so YMMV.

Fedora Core 5 Support for Intel Pro Wireless (Centrino)

I bought a new Gateway MP6954 Laptop yesterday and decided to give Linux another go. This time I told myself: I’m not even going to attempt to run any Windows applications using Crossover Office or anything else. I’m just going to go with what works best: httpd, Tomcat, Java, PHP, Perl, Ruby, Oracle, MySQL, etc.

I installed Fedora Core 5 again (kernel build 2.6.15-1.2054_FC5smp) from the same CDs I used last time and it installed and came up cleanly, but with no wireless support. There is very little documentation about running Linux on my particular laptop model, but the wireless hardware (Intel Centrino/Pro Wireless ipw3945) is fairly commonplace and, according to the many sources I referenced, it’s “well supported” by Linux. Intel even offers a driver for it, but it’s a source-only distribution.

According to the install guide for the driver, I first needed to download and compile the IEEE 80211 subsystem. I later found out that in most cases, doing so is a bad idea. Compiling the subsystem (version 1.1.14) and then the driver (version 1.1.0) led to runtime incompatibilities — “Invalid Module Format” was the exact error. However, against the 80211 module included with the 2.6.15 kernel source, the driver wouldn’t even compile. So I was in a bind.

I needed to find an IEEE 80211 subsystem that was compatible with the 1.1.0 version of the driver. The answer was actually more simple than I thought. All I needed to do was upgrade to the latest FC5 kernel 2.6.17, install the latest kernel sources (yum install kernel-devel) and then build the driver from there. These are the instructions I followed.

And just like that, I had wireless support for my new laptop under FC5. Now only if I could get the sound card working . . . .

Cracking open ISO files

I’ve been doing a lot of installing and re-imaging lately 🙁 and I’ve had to work with ISO files quite a bit. I haven’t found any Windows freeware that writes ISO files to CDs that actually work. However, I did discover that WinRAR has built-in support for extracting ISO files onto your hard drive.

It won’t, however, help you burn an ISO to a CDR, but hopefully with this info you might not have to!

(By the way, Mac OSX has native support for burning ISOs to CDs built into the operating system.)

Adventures in desktop linux

I’ve had such a good experience using Fedora on several of bdg’s enterprise systems (SugarCRM, Subversion, Bugzilla, Vetrics, Connotea, etc.) that I thought I would give desktop linux a shot.

What a mistake.

Actually, it was a good learning experience. But still, a mistake.

First I download Fedora Core 5 (Bordeaux) using BitTorrent. My first problem was mastering the ISO files to CD. Windows has no native support for this (surprise) and for the life of me I couldn’t find a free product without filesize restrictions or other issues. Finally I remembered that I had a purchased a license for Sateira DropToCD some time ago, so I attempted to use that miserable excuse for a program. I tried to burn the five CDs at 24x (~10 minutes each) and my computer would not recognize them. The CD-Rs, once burned, were useless, yet Windows did not show any data on them nor a volume label.

I did a little Googling and then remembered that I needed to burn at 4x in order to get Fedora Core 4 (and Solaris x86 — another mistake) to work. So I tried that (at ~30 minutes per CD) and again, total failure. Finally I used a real operating system, OS X, running on my wife’s Mac laptop, to create the ISOs. (Of course OS X has built in support for ISO burning that works like a charm.)

After all this nonsense, I was finally ready to install FC5. So I backed up all my company files, music, photos and other stuff to my Western Digital 250 Gb external firewire drive and off I went.

I must say, there are some nice things about FC5. Unfortunately, it’s a short list:

  1. The installer, Anaconda, is awesome.
  2. The graphic design is beautiful.
  3. Wireless networking just works.
  4. Firewire just works.

So I was off to a running start. But here is where my problems began. At the top of my shit list is CodeWeavers‘ CrossOver Office. What a complete piece of garbage. From all their press releases, I was led to believe that they actually supported some useful Windows programs such as Office and, more recently, iTunes on various flavors of Linux. Don’t believe what you read. It’s all lies. Damn lies.

I started with Office 2003. That just failed utterly and completely. I wasn’t about to go back to Office XP, so I gave up on running M$ Office. FC5 comes with OpenOffice, which claims to support Word, Excel, etc. so I figured I would just use that.

Next I moved to iTunes. First off, installing it is a series of hacks and kludges. Upon following these ridiculous instructions, iTunes actually launched! But:

  1. All my playlists were gone, even though I repeatedly pointed iTunes to my backed up iTunes Music folder.
  2. The best feature in iTunes, search, didn’t work — the search box was grayed out.
  3. A basic feature — scrolling — was inconsistent and buggy.
  4. It crashed about 10 times before I completely gave up on it.

So now I had limited options. I decided that I would give up on purchasing DRM music through the iTunes store (and save about $500/yr in the process) and switch to Banshee, which claimed to be everything that iTunes was minus the music store.

Okay, so music is just music. But what about e-mail? I’m totally addicted to Outlook — the proof is my 1.5+ Gb .pst saved mail file. Without CrossOver Office running Outlook, I had to fall back on Evolution or Thunderbird. Access to saved mail, however, was a showstopper. To use my gi-normous .pst file in a non-M$ program, I needed to convert it to MBOX format. That proved impossible. Or at least not possible within my own personal constraints of time, patience and most importantly, sanity.

First I tried Thunderbird, because I remembered using its Outlook .pst conversion program. After struggling for a long time with compilation issues, linking issues/missing dependencies (including the wrong version of libstdc++) and segfaults, I finally got the ol’ T-bird working on FC5. But to my disbelief, the option to import a .pst was missing. After some Googling, I found out that Mozilla’s hairbrained implementation actually relies on MAPI, so you need to have Outlook installed and configured on the machine with Thunderbird in order to convert from .pst to MBOX.

I tried various other programs, including a useless dungheap called MailNavigator. I also tried hand-compiling a C program called libpst that was supposed to work and didn’t. I was beginning to think that my .pst file had been corrupted, but that was impossible because it was running fine in Outlook.

After all this nonsense, I used my wife’s laptop to download a DOS book disk with fdisk, deleted all my partition info, and now here I am back on Windows XP.

Lessons learned:

  1. Linux is not ready for the desktop, even if you’re a hardcore developer.
  2. Don’t believe anything CodeWeavers say about CrossOver Office. It just doesn’t work. Period.
  3. Windows, for all its faults, is actually not that bad. I can’t believe I just said that, but it’s true. 😉