Rails – The Missing Parts – Policies • Hacker News Board

Re: Rails – The Missing Parts – Policies

#61

Post by karmajunkie » Fri, Mar 21, 2014, 6:40 PM UTC

swanson wrote: post #39

How is a Policy different than an ActiveRecord::Validator? Could this TicketPolicy not just be a validator extracted to it's own file (and tested on it's own)? http://api.rubyonrails.org/classes/ActiveModel/Validator.htm...

Policies (also known as strategies) aren't altogether different from Validators, though they're a bit more flexible. The real difference is that validation doesn't belong on your database interface, and its the chief reason why AR can only be used for domain driven design in the most basic of circumstances (NB: this isn't the same as saying that database constraints are a bad thing.) Validators are hardcoded into models; in that regard, they're only slightly more flexible than using validations directly on the model. Like Rails' notion of concerns, they're really about code geography, not architecture or design.

Policies, on the other hand, are far more flexible (assuming your application interface supports them, or they're used to wrap a block, or some other gatekeeping mechanism) because they can be swapped out. Imagine a circumstance in which you want one set of validations for creation by a normal user, and another set of validations when the creation of an instance occurs through a privileged API; yet another set of rules for creation by an admin, and so on...

You could implement those as a series of validators with an :if option on the validates call, and if you want to stick with Rails' canon, go right ahead. But in my opinion (and having made this mistake before) you're simply staving off an inevitable point at which your dependence on Rails has hamstrung your ability to iterate code.

Re: Rails – The Missing Parts – Policies

#62

Post by dpeck » Fri, Mar 21, 2014, 7:32 PM UTC

planckscnst wrote: post #25

dpeck wrote: post #18

Earlier quoted context omitted.

Curious is you have some more details about this written up anywhere or some code on github? I'm just using Pundit in a "real" app for the first time where strict user types won't be enough and I need to have a role based approach. I'm doing something similar to what you have now, but a couple steps back in my design process, and the managable concern sounds promising.

That would be a good idea for a writeup. I'll have to get that done. For now, I have a couple more details. We're using the closure_tree gem to give a hierarchy to the permissions; every permission can have a parent, which may further limit which abilities are allowed on a managable by a manager. This means that if user A has abilities "1,2,3" on an object, when he grants a permission to user B, while he can create t…

awesome. I'd definitely like to see a full writeup if you ever do one, email is in my profile.

Re: Rails – The Missing Parts – Policies

#63

Post by briantakita » Fri, Mar 21, 2014, 10:23 PM UTC

phillmv wrote: post #34

briantakita wrote: post #32

Earlier quoted context omitted.

The solution I describe is basically a functional approach. The function is responsible for the policy concerns over all data in the system. The function itself can be decomposed into smaller functions. If you need extensibility, you could make the function composable and register additional pieces to the policy. Most codebases don't need this sort of extensibility. Simple constructs & consistent, accurate, precise n…

:%s/function/module/ and no meaning is lost :). I've yet to catch up on my lisp and fully grok the "functional paradigm" and, admittedly, passing around consts is less elegant than passing around function pointers, but what you're describing sounds isomorphic to me in terms of code organization. Look at the blog post; he's just passing a one method class, which… is basically a less elegant function.

> :%s/function/module/ and no meaning is lost :).

Javascript has functions, from the function keyword. Node.js uses commonjs. In commonjs, every file is a module. You can use

module.exports = ;

You can access the module by using require.

var moduleValue = require("path/to/module");

It's powerful because it doesn't have the namespace collisions that Ruby has. Everything is not global all the time. modules are also an elegant way of holding private state using closures.

Having a class with a single method is the Ruby way of categorizing this method within the domain.

Re: Rails – The Missing Parts – Policies

#64

Post by nthj » Fri, Mar 21, 2014, 11:53 PM UTC

highpixels wrote: post #53

nthj wrote: post #50

Earlier quoted context omitted.

> Additionally, I find that the key problem with bloated models stems from missing domain models (often has-many-through models). Not from moving the logic of the existing models into more noun classes. When I first started learning Rails 4 years ago, I watched a video of a talk you gave where you refactored a kludgy piece of code to use an additional resource/model. The code unraveled before our eyes. I still rememb…

Don't suppose you have a link to that video? Or remember any more details so I could dig it up?

I think it was this one, but unfortunately I can't find the whole video.

https://www.youtube.com/watch?v=mp4z2eK1Avw

http://johannesbrodwall.com/2007/02/27/crud-rest-rails/

Re: Rails – The Missing Parts – Policies

#65

Post by jvans » Tue, Mar 25, 2014, 1:11 AM UTC

I think this is a responsibility that lies in the model. What if you decide to allocate tickets through a different model? You have to remember to include this policy everywhere. Another approach i think is reasonable is creating a class for this on the model level.

https://gist.github.com/jvans1/9745395