Thursday, October 25, 2007


Author’s Note: I actually wrote this back in 2006, but it kind of fell through the cracks. So I present it now, for your amusement/pleasure/whatever…

The term “Web 2.0” has become synonymous with AJAX. With the hype and buzz that’s surrounded “Web 2.0”, people seem to invent reasons for using it. Even when it makes no sense. Sometimes especially when it makes no sense. Just because it’s “cool!”

ZooDotCom Presents - AJAX is X-TREME!!!

Oh yes, AJAX is cool. It can really enhance the user experience of your application. And yes, you can do some interesting single page applications that don’t require a server. But hopefully you’re not quite as gung-ho about it as Charlie here (from the comic above). Rails makes it easy to use AJAX. Really easy. Too easy? Perhaps. And occasionally even I’ve been sucked into the trap of throwing out a quick, AJAXified, solution rather than taking the time to build it right, to build it compatible with the “Web 1.0” (or non-JavaScript enabled) folks. But I shouldn’t have. And neither should you.

ZooDotCom Presents - Fine, then how do I it?!

That, Charlie, is a good question. In my next post I’ll talk a bit about Comatose, and how I went about ensuring that it’s backward compatible with non-JavaScript enabled browsers.

Author’s Other Note: I will post the second part to this soon… Probably next week. Cheers.

Friday, June 29, 2007

Comatose 0.8.1

It’s been a long time coming, but it’s finally here: Comatose 0.8.1!

Over the next few days, I’ll be transitioning the project to Google Code and Google Groups please start using them for reporting bugs and such. Here are the important URLs:

I’ve also updated the docs to reflect the new 0.8+ way of doing things. They’ll wind up on the wiki so that they’ll be easily maintained by all.

From the changelog:

  • All includes and helpers are loaded at the end of the ComatoseController and ComatoseAdminController classes
  • Fixed the ComatoseController#show action to correctly send an HTTP status of 404 even if it finds, and renders, a page at ‘/404’
  • Fixed the migration to default a page’s full_path to ” instead of null
  • Formalized ComatoseDrops. Use Comatose.define_drop "drop_name", do ... end. Every method within that block should return a value for use with a Liquid and/or ERB template. Usage in a comatose page: {{ drop_name.def_name }}
  • Added support for a config.after_setup block that gets called after Comatose is setup (in the Dispatcher#to_prepare event)
  • Added HTML comment output for calls that result in a method_missing on the ProcessingContext
  • Updated page tree to remember collapsed/expanded nodes between page visits
  • Fixed some errors that were caused by null revisions (usually happened after initial installation)
  • Added my javascript test_runner lib for testing slugs generated by JavaScript. More JS tests to come.
  • Bugfix #8640 (rubyforge bug)

For more see the devblog

Monday, February 19, 2007

Sorta Nested Layouts

I was playing around with layouts in Rails the other day… I know, clearly I have too much time on my hands. But anyway, I found that you can fake a nested layout scheme in Rails by delegating view rendering to partials. As an added bonus, you don’t need to hack around with any of Rails’ internals to make it work.

For example, let’s say I’m working on an application that has both a public layout and an admin layout. The public layout consists of tabs and a sidebar. The admin layout has different tabs and no sidebar at all. Both layouts share a site header graphic.

With that in mind, here’s how we could structure our layouts and partials:


<title>Layout Example</title>
<div id="header"><!-- shared header code --></div>

<%= render :partial=>"layouts/#{controller.sub_layout}" %>

<div id="footer><!-- shared footer code --></div>

Note: I’m getting the partial name from a controller method named sub_layout. I’ll explain that bit in just minute—In the meantime, knowing that it’ll return either ‘public’ or ‘admin’ is enough.

You’ll notice I don’t have a call to <%= yield %> in the layout itself…

So then, your partials (or sub layouts) will look something like this:


<div id="tabs"><!-- public tabset --></div>
<div id="public-content">
<div id="sidebar">
<!-- sidebar content here -->
<%= yield %>


<div id="tabs"><!-- admin tabset --></div>
<div id="admin-content">
<%= yield %>

Ah, there’s the <%= yield %>! That’s how you can delegate the view rendering. Basically, you’re using a partial to wrap HTML around the call to <%= yield %>.

OK, in the application.rhtml listing above, I get the partial that works as a sub layout from the controller. To hook that up, in your ApplicationController, you can specify a default sub layout like this:

class ApplicationController < BaseController

# .. your actions

def sub_layout


Then in any administrative controllers, you can override it:

class UsersController < ApplicationController

# .. your admin-like actions

def sub_layout


I went ahead a threw together a little example application to better illustrate:

Perhaps the example of different tabs and sidebars isn’t most compelling reason to use sub layouts—Which is fine. The key point to all of this is that you can delegate the rendering of your view from a layout to a partial. Which I’m sure you can leverage in all kinds of cool ways…

Tuesday, January 30, 2007

Comatose 0.8 Released

Tada! Comatose finally supports Rails 1.2!

In fact, it only supports Rails 1.2 now. If you are still on Rails 1.1, don’t upgrade Comatose — It won’t work. Consider yourself warned. (version 0.7.1 is tagged, so all you Rails 1.1ers can still get to it)

OK, so I made quite a few changes whilst upgrading Comatose. No functionality was removed, yet, but enough has changed that we should hit the high points here… I’ll post a more in-depth article on the dev blog later.

First up, there’s a new configuration system. It’s quite dandy, really. It single-handedly made the DEFER_COMATOSE_LOAD and controller class hacking obsolete.

You can still use all the same old settings, only you set them in a configuration block in your environment.rb now. Here’s an example from an app I’m currently working on:

Comatose.configure do |comatose|
  comatose.includes << :authenticated_system
  comatose.helpers <<  :application_helper
  # admin
  comatose.admin_title = "My App's CMS"
  comatose.admin_sub_title = "... its' fun for the whole family!"
  comatose.admin_includes << :authenticated_system
  comatose.admin_helpers << :application_helper
  comatose.admin_authorization = :admin_required
  comatose.default_tree_level = 1
  comatose.admin_get_author do
  comatose.admin_get_root_page do
    roots = %w(public-root content-fragments)
    roots.collect {|path| Comatose::Page.find_by_path(path)}

Look over that example closely, there’s a lot hidden in there.

  • comatose.includes is an array of module names (as symbols) that will be included in the ComatoseController.
  • comatose.helpers is also an array of module names, only these are loaded as helpers so you can use them in a view, most likely in your layout.

Remember, you no longer extend ComatoseController to add functionality. * All that holds true for ComatoseAdminController and the comatose.admin_includes and comatose.admin_helpers as well. * comatose.admin_get_author and comatose.admin_get_root_page both accept a block of code that should return the author and root_page respectively.

You can use any default controller method, as well as methods from included modules * comatose.admin_authorization is using a method from an included module directly, the :admin_required method from the AuthenticatedSystem module.

The options that accept blocks will also accept symbols representing module methods. * Have a look at the config class for all the options

Also, there are unit tests now. Yay!

You can get an overview of the coverage, if you like. Oh, using rake test:plugins doesn’t work, to run them you will need to change into the vendor/plugins/comatose directory and run rake, after you’ve run the Comatose migrations.


  • Now ONLY supports Rails 1.2 (not even tested in Rails 1.1)
  • New configuration system
  • DEFERCOMATOSELOAD is gone — Using Dispatcher.to_prepare replaces it
  • You no longer extend the base classes to add functionality. You configure Comatose to include modules and send it symbols for providing said functionality. e.g. Comatose.config.includes << :authentiationsystem; Comatose.config.authorization = :requirelogin
  • The automatic loading of RAILS_ROOT/lib/comatose/*.rb files is NO longer supported.
  • In addition to mapping comatoseroot in your routes.rb, you’ll want to map.comatoseadmin as well

Obviously, if you have any issues with this version, please let me know.

Monday, January 22, 2007

Comatose, TaskTHIS, and Theme Support. Oh My!

Well, I’ve been a little remiss in my open-source development of late. Many apologies, things have been a bit hectic. You know the feeling, I’m sure.

But that’s not why I’m posting. I thought I’d outline my ideas for the future of these projects and get your feedback and/or ideas.

Comatose, The Micro CMS Plugin

The things that are definitely coming…

Edge Rails - Since Rails 1.2 is now official, it’s time to finally support ‘edge rails’. :-D

Actually, I have a version that runs on Rails 1.2 now, but I’m debating about Rails 1.1 backward compatibility. The new version changes quite a bit. The DEFER_COMATOSE_LOAD stuff goes away, replaced by better configuration support and a Dispatch::to_prepare block. Plus you no longer override the ComatoseAdminController for authentication, instead in the configuration you specify modules to include in the class. Oh yeah, and the controllers no longer extend ApplicationController.

Test Harness - The tests in the plugin itself are very spartan, at best. I have a horribly ugly test harness I use for the actual unit testing that I’m going to clean up and release.

Some possibilities

Liquid Only - I really think I’m going to drop ERb support. How many of you use ERb over Liquid for page processing?

RESTful Pages - Perhaps using the new RESTfully CRUDDY support would be useful. The idea of having an API for pages is interesting.

Mount Behaviors - I haven’t thought this through yet, it just popped into my head: map.comatose_root 'devblog', :index=>'blog', :behavior=>'blog'

This example would add ‘blog-like’ support such as all children being paged entries (showing last 10, next page, last page, etc.), automatic hAtom microformat support, and maybe some sort of archives… I don’t know. I still haven’t thought about this too much.

The behavior support would be pluggable, much like text-filters and drops… Can you think of any other behavior that would make sense?

Maybe :behavior=>'syndicated' to create RSS/ATOM feeds of the child pages? Perhaps they’d be mixable by saying :behavior=>'blog syndicated' or :behavior=>'blog,syndicated'.

The probably nots

Media Management - It just feels like too much. I have a hacked up version of Comatose that supports page attachments. But you wind up having to deal with upload directories, and file permissions and… It just feels too heavy. And too heavy != micro.

Perhaps it could be a separate plugin?


TaskTHIS is getting a bit long in the tooth. It was written right about the time some of my AJAX patches were being added to Rails. Which was pre 1.0. So, yeah. It needs some love.

It was created as a show-and-tell for the then-new-and-nifty AJAX support. Which, of course, is now old hat.

In keeping with the tradition of show-and-tell, I thought TaskTHIS would be an excellent application to show how to use the new CRUD/REST/Resources stuff in Rails 1.2.

I have a few ideas outlined here. The biggest ones are:

API - This is fairly straight-forward, we’ll get most if it from Rails. We’ll just add the appropriate authentication for the XML requests.

OpenID - I was thinking replacing the existing login system with OpenID authentication. I like the idea of just typing in my domain to login… Who needs passwords? Seriously though, this may be a bit controversial — please weigh in.

Oh, I forgot to mention, is working again.

Theme Support Plugin

Basically, just add any outstanding patches and ensure it works on Rails 1.2. I imagine the routing stuff will need to be tweaked.

Whadda Ya Think?

What would/wouldn’t you like to see in any of these projects?