On Mon, Jun 25, 2012 at 4:48 AM, Robert Rothenberg <[email protected]> wrote:
> Several DBIC classes in our application have been customized with a method
>
> user_can_modify($c)
>
Do you really need the context? I think the suggestion is normally pass in
the data you need, which I suspect is a user object. Then you are not
binding DBIC and Catalyst so tightly.
user_can_modify( $user ):
Sure, you can mock up a context object, but for flexible to pass in only
the data you really need.
I use a variation of that an added a "current_user" attribut to the schema.
Then in ACCEPT_CONTEXT in my DBIC model I have:
$schema->current_user( $c->current_user );
And likewise, in a unit test where you have a schema object you can
explicitly set the user.
Then the "can_user_modify" can be tested in the DBIC class directly
enforcing your access rights lower in the stack.
If you have a "model" layer between Catalyst and DBIC then you would
probably want to put that there, instead. We are also doing that now.
In one project we use joins instead of calling separate methods to check
the user has correct access. I'm now moving away from that and instead
using more discrete calls to be in a better position for caching.
--
Bill Moseley
[email protected]
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
