contentFor.functional.jade

// I don't like this style because it eats up so much of the namespace.

#{ setContentFor('title', '...') }

h1 #{ yield('title') }
h2 #{ yield('subtitle', 'some default value' } // get if set, otherwise set then get

if #{ hasContentFor('sidebar') }
  aside.sidebar
    #{ yield('sidebar') }

#{ appendContentFor('footer', '...') }

contentFor.namespaced.jade

// This is what I've implemented, and I like it, but I might like the proxy version better.

#{ contentFor.set('title', '...') }

h1 #{ contentFor.get('title') }
h2 #{ contentFor.fetch('subtitle', 'some default value' } // get if set, otherwise set then get

if #{ contentFor.exists('sidebar') }
  aside.sidebar
    #{ contentFor.get('sidebar') }

#{ contentFor.append('footer', '...') }

contentFor.proxy.jade

// Instead of contentFor being a namespace, it could be a function that puts
// you in the context of the content for a particular key. This really appeals
// to me, but I'm not sure it's as intuitive as the namespaced version.

#{ contentFor('title').set('...') }

h1 #{ contentFor('title').get }
h2 #{ contentFor('subtitle').fetch('some default value') } // get if set, otherwise set then get

if #{ contentFor('sidebar').exists }
  aside.sidebar
    #{ contentFor('sidebar').get }

#{ contentFor('footer').append('...') }

I like the proxy version, too; my biggest concern with the functional version is the term "yield", which is a Rubyism and may not mean much to JavaScript programmers.

It's actually fairly easy to do both the namespaced and the proxied version. The namespace is simply a function that takes a single argument and curries it.

I think this sort of thing would be great for an Express-extras type of contrib lib, which I have been meaning to get started with goodies that might not necessarily belong in core