04 August 2009

Tabbed Navigation for Rails

When I start a new rails app and write a tabbed menu, I always postpone the moment I'll determine how it's going to set the current tab. And when it comes to it, I usually do quick and dirty stuff with the controller name, the @category.name or whatever. But last time, facing a step by step form you could navigate through with tabs, I thought "enough of it I need a solution once and for all".

Sooo, looking at plugins first tabnav seemed to be the reference. But I wanted something i could easily tweek and understand, and this was just overkill for me needs.

Then I looked at the free for all tab helper which has some very interesting solutions, the most elegant being the one relying only on css and the body tag (no logic involved). But that wasn't flexible enough, they were all making the assumption the tabs would switch controllers.

So having to get my hands dirty I first refreshed my memory with my favourite source of hints and came up with what I believe is a very elegant and flexible solution.





This is minimalistic but you can see that it is very easily extendable. The main idea is that you are sendind to the tab class a matcher that is going to set the current tab.

My matcher was a bit complex as you can see below(it also sets the partial to render), but keep in mind that you could do exactly the same like this :

tab_for :controller => controller_name do |t|
...

and it works with no further logic.




What I appreciate most is that the logic for matching the tab is kept seperate ( it only relies on the params inside the links ) and the "tab_for do" syntax is very railsish & familiar.

2 comments:

Anonymous said...

Hi, why not use what's already there? Have a look at uberkit [http://github.com/mbleigh/uberkit/tree/master] or its forks for further features :-)

Charly said...

Thanks for the link.

I looked at the code and indeed my tab solution is a lot like a very simplified version of ubbermenu (identical structure at least). The tradeoff is the flexibility and simplicity you loose when using a "do it all solution".

Besides i prefer my view of the matching logic which is independent from the current_page? and is more explicit since its the first argument you see.

However i do like mbleighs code, using it with acts_as_attaggable-on.