Haml be blowing my spot

I've heard of the awesome that is Haml before. I've had friends rave about it. But it was only recently that I broke down to actually use it.

So I went forth and migrated my blog's rhtml templates to haml. Hell, I even migrated my resume from straight-up html to Haml.

It's good. Really good. But, I have some regrets.

One of the features of haml is to automatically pretty-print your markup. But, can you think of any elements that would probably be better left un-pretty-printified?

  • <pre>
  • <textarea>

So, if you're wondering why my code snippets are all skewed, you have your answer.

I haven't found a good work around yet. An obvious answer would be using filters, but this doesn't quite work since I have markup stored in my model. There seems to be a :dirty option for Haml which doesn't format things, but I haven't quite found out how to flip that switch.

So the search continues.

Permalink Edit Destroy

Follow up: Haml no longer be blowing my spot

I just barely posted about Haml blowin my spot. Thanks to the kindness of a reader, Haml is no longer blowin my spot.

The problem

Imagine we have the following snippet:

%div{ :id => "post_#{ post.id }" }
  %h2{:class => 'post_title'}= post.title
  .post_content= post.cached_content

This post.cached_content contains some <pre> tags. As a result, the contents get kind of skewed.

The fix

So, it seems you can do something like:

%div{ :id => "post_#{ post.id }" }
  %h2{:class => 'post_title'}= post.title
  .post_content~ post.cached_content

The key here is that we use ~ instead of = to output stuff. Apparently this is an alias for Haml::Helpers.find_and_preserve. I actually didn't see any documentation about this alias though.

Looking to the future

Nathan Weizenbaum also pointed out that "Incidentally, as of Haml 1.9 pre and textarea will automatically eschew indentation-management." Sick!

Permalink Edit Destroy

Boston.rb Hackfest 4/15 Post Mortem

Last Tuesday, we had a small, but dedicated showing at the Hackfest:

Going in, we didn't really have a something in mind to work.

We thought to pick up the app we started in merb for organizing katas. But when it came down to it, we figured it'd be a lot quicker if we just did it rails.

We actually wanted something a little more general, kind of a one stop shop for Boston Ruby stuff. Here's what we wanted:

  • Keep track of events (meetings, hackfests, and katas)
  • Projects that have come out of above-mentioned meetings
  • Recent commits from these projects

Tools we used:

You can see the code we ended up with in the hackfest repository.

Or, you can see it in action.

For simplicity's sake, we didn't initially bother with users/permissions/etc, so be gentle with it.

Permalink Edit Destroy

Boston.rb Hackfest 4/29 Post Mortem

So, we were just kidding about working on the recommendable plugin. We actually worked on the bostonrb.org website some more.

The crew tonight was:

The significant things we worked on were:

  • Projects have descriptions now
  • Events now have a location
  • Reorganized events page
    • left side has all upcoming events
    • center has next event with google map
    • right side has nothing now, but we're thinking to put a calendar type view

Some articles, resources, that came up while hacking away:

The fruits of our labor have been pushed to http://bostonrb.org, and the source can be found at https://svn.thoughtbot.com/hackfest/boston_rb.

Permalink Edit Destroy

Better partials with better-partials

The other week, Dan Croak pointed out better-partials to me. Hadn't gotten a chance to play it until now.

The gist of better-partials is that it's a syntactical sugar for render :partial.

Here's a typical haml snippet using a partial:

- form_for(@video) do |form|
  = render :partial => '/videos/form', :locals => { :form => form }

With better-partials, we can refactor it to:

- form_for(@video) do |form|
  = partial 'videos/form', :form => form

This saves a little typing, and makes it a bit more clearer:

  • You just say you want a partial, rather than to render a partial
  • Automatically passes in options to :locals (with a few special exceptions)

There are a few other usages of better-partials, but I haven't gotten to use them yet.

It's not that big of a deal, but it seems like a nice little improvement to me.

Permalink Edit Destroy