constructor to perform mass-assignment about virtus HOT 12 CLOSED

I haven't decided yet to be honest. I'm not sure if Virtus should be responsible for filtering out user input. I treat this library only as something which allows you to define your models via attributes API + it comes with coercion system.

"Mass-assignment security" is something that you only need in special cases where you have to deal with user input which can contain, well, basically anything. It seems to me like filtering out params is something that should be done by one of the web-framework 'layers'.

Even if we agree to build this into Virtus I'd prefer to have it a separate module that you can include only if you need this.

@dkubb Again, WDYT?
@emmanuel Don't you think conformitas would be a great place to deal with mass-assignment security?

from virtus.

I wasn't refering to mass-assignment security I just meant to be able to do something like:

class Example
  include Virtus

  attribute :name, String
  attribute :age, Integer
end

Example.new :name => 'test', :age => 10

without protection or anything like it. Of course I could extract the common constructor into a module and just have that code in my application but I wasn't sure if it should be a part where virtus could assist.

from virtus.

@senny oh! sorry - this is already built into Virtus: https://github.com/solnic/virtus/blob/master/spec/unit/virtus/class_methods/new_spec.rb#L13

from virtus.

@solnic sorry for the confusion and thanks for the hint :)

from virtus.

@senny no problem; at least this reminded me about mass-assignment security :)

from virtus.

@solnic regarding mass-assignment I like the approach described here: https://github.com/emmanuel/conformitas

from virtus.

@senny yup, me too. It seems like a proper place to handle this

from virtus.

Actually I really like the approach @emmanuel is taking with that, having an object who is responsible for handling form input and display.

I think the tendency in the ActiveRecord world is to try to jam as much functionality into the AR objects as possible. That's how you end up with 500 line long User classes, or classes that have lots of different concerns. I totally understand why though, it's easier to get started with because you don't have to put any thought into organization, you just start writing code.

The thing is, this easy-to-get-started approach makes for some much more expensive maintenance in the long run. You end up with objects that are much harder to test. They are often coupled to the database, so the tests become slow. Anything that's harder to test is going to usually be buggier and less well designed and refactored because you can't TDD it properly.

I would much rather work with loosely coupled objects that know almost nothing about each other, other than agreeing on some simple protocol. It should be possible to swap out parts of Veritas, Virtus, Aequitas, etc with something API equivalent and not have to rewrite the whole stack. It should be possible to substitute those objects with mock objects that don't require very much setup either.

This approach does mean a slightly higher barrier to entry. I think I'm fine with that as long as the benefit is there later on. I've come onto too many Rails projects where most objects have multiple responsibilities, are tightly coupled to each other, hard to test, and coupled to the database. We're hoping to design something that can avoid much of this mess.

from virtus.

@dkubb well said! That's what got all my interest in the DataMapper 2.0 Roadmap. AR makes it really hard and takes a lot of design decisions from you. When you totally isolate it to get control over your architecture you loose most benefits of using it.

from virtus.

@emmanuel Don't you think conformitas would be a great place to deal with mass-assignment security?

@solnic —

That's one of the major reasons I want to build conformitas: to externalize mass-assignment security responsibilities out of the models themselves. Filtering input to the models is a core responsibility of a form object (along with validating that input).

Handling input in a separate (form) object makes that filtering incredibly simple: a form object's list of attributes (with public writer methods) defines what input is acceptable. Eg., attributes with public writers replaces attr_accessible. Incidentally, the whole whitelist vs blacklist issue also disappears: blacklist-based filtering is no longer an option.

from virtus.

Oops, sounds like everyone here agrees that a form object is a win, I don't need to preach the benefits.

I should have read through the rest of the thread before responding :).

from virtus.

@emmanuel surprise! we're on the same page! ;)

from virtus.