Defaults and showing tabs through authorization tools

So, I'm just getting started with Tabulous, and I'm liking it so far. But, I already have a central place in my application for determining who is allowed to access what, which is my Consul powers. I imagine people using CanCan, Pundit, etc have similar setups.

This results in me having a lot of tabs with code like this

users_tab do
  ...
  visible_when { current_power.show_tab?('users') }
  ...
end

products_tab do
  ...
  visible_when { current_power.show_tab?('products') }
  ...
end

It's not very dry, so I was wondering, what do you think adding tabset defaults to the DSL?

Something like this:

defaults do
  enabled_when {|tab| current_power.show_tab?(tab.name) }
end

The actual tab class could stay entirely the same. The change to the DSL would be fairly simple as well; the core of it would be:

def use_default(key)
  if (default_block = @defaults[key])
    tab = @tab
    block = Proc.new { default_block.call(tab) }
    @tab.send(:"#{key}=",block)
  else
    raise MissingDeclarationError.new('...')
  end
end

I've left out collecting the defaults in the tabs block and passing them to the DSL::Tab object, but that part is fairly straightforward.

Thoughts?

Thanks for using tabulous and for the idea!

I see exactly the problem you're solving--you communicated it quite well--but I'd rather not take tabulous in this direction and here's why.

Don't Repeat Yourself has been a great mantra of the Rails community which combats the tendency of new programmers toward "cut and paste programming" and also leads toward simpler design. I think what's been lost, though, is that the problem is not so much with repeated code as much as with a piece of information in a system being represented more than once. This can happen in any system, not just code. For example, consider there are two ways you can apply for a city permit: online or with a paper form. Now consider the permit cost increases from $25 to $35. You will have to change the instructions on two forms. The danger is that when you start to have a complicated system and you don't follow the discipline of representing a piece of information only once in the system, you will start to introduce bugs because it's difficult to find all the different places that fact is represented in the system. This is the main value of DRY.

The essence of the problem you brought up here is tedious repetition, not the same fact being represented in multiple places. Just because tab #1 and tab #2 have the same exact authorization rules doesn't mean we have a repeated fact, just related facts.

I think the repetition actually adds to code clarity because relevant information is kept together.

I also am very hesitant to add anything new to tabulous as I want to keep it simple, which unfortunately means even good ideas.

Sorry for the long-windedness of the answer, but I wanted to give you the courtesy of explaining my rationale since you had the courtesy to offer up a new idea.

techiferous / tabulous

Defaults and showing tabs through authorization tools #54