Rails – The Missing Parts – Policies

Oh boy, is DHH going to jump into this too?

As an intermediate Rails developer...I don't understand why this if/else forest:

    if user.blacklisted? # They've been banned for bad-behaviour
      fail! “You can't book a Grouper at this time”
    elsif grouper.full?
      fail! “This grouper is full, please pick another date”
    elsif grouper.past?
      fail! “This grouper has already occured!”
    elsif user.has_existing_grouper?(grouper)
      fail! “You’re already going on a Grouper that day”
    elsif ticket.confirmed?
      fail! “You’ve already confirmed this grouper”
    end

-- can't simply be part of the Ticket object? The Ticket clearly has a relation to User and Grouper and talking to those objects (i.e. `if user.not_blacklisted? && user.not_booked(self.date)`) don't violate Demeter...how is making a policy object cleaner than just using a Concern that is included into Ticket? The controller then just needs to ask for `ticket.confirmable?`

edit: OK, not ask for `ticket.confirmable?`, but rather, try to `save` the ticket and the Ticket constructor/validators can pass on the errors to the controller.

If I can overly generalize, and as a person who generally loves Ruby and Rails, I'll suggest that there are two schools of Rails app development emerging.

The first is what I'll term the "Classic School" or "DHH School" characterized by full-blown utilization of all Rails magic such as AR/AC callbacks, pretty skinny but not obsessively skinny controllers, an eschewance of service objects and more.

The "Emerging School" relies less on some aspects of Rails magic, and introduces patterns like services/interactors/DCI and seems to be more focused on building a domain models which attempt to be less coupled to the framework.

I think the Grouper folks are in the second camp given their previous blog post about interactors which showed up here on HN. Also, I think the desire to encapsulate authorization into a reusable object seems slightly more in the spirit of the emerging school.

What I find odd is that they'd offer a solution for authorization which is so bound up in Rails magic. It seems to me authorization is really part of the domain model and as such you would expect to find that code in whatever gets called by the controller (which I would expect to be something like an interactor, but in this blog post is just plain old Rails code.)

I would use CanCan ability.rb file for that: https://github.com/CanCanCommunity/cancancan

I know this isn't the point of your comments, but I'll take the opportunity to point out that Ruby has a case statement that reads a lot better for code like this:

  case
  when user.blacklisted?
    # ... code ...
  when grouper.full?
    # ... code ...
    # ... and so on ...
  end

Ha! Yes. Exactly so.