Zach
By saying that models need the following case statement
def by_role(role
case role
when "associate"
when "admin"
...
end
your implying that the model is represented in a different way depending on
the role. So in your case of invoices the associate's view
On Tue, Mar 3, 2009 at 12:32 PM, Pat Maddox wrote:
> On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote:
>> On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote:
>>>
>>> Forgot to mention what we did do. We ended up with the following...
>>>
>>> def index
>>> if user.has_role?("admin")
>>> user
On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote:
> On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote:
>>
>> Forgot to mention what we did do. We ended up with the following...
>>
>> def index
>> if user.has_role?("admin")
>> user.in_role("admin").invoices
>> elsif user.has_role?("associat
On Tue, Mar 3, 2009 at 11:07 AM, Andrew Premdas wrote:
> I think this discussion has gone backwards a bit. Here is what I think the
> index method in the invoices controller should be like
>
> def index
> begin
> invoice.get_collection
> rescue
> # decide what to do if we can't get coll
I think this discussion has gone backwards a bit. Here is what I think the
index method in the invoices controller should be like
def index
begin
invoice.get_collection
rescue
# decide what to do if we can't get collection
end
end
Now clearly this needs some work to get it to work ..
Mark Wilden wrote:
>
> You do consolidate all your _access_ logic in one class, just as you
> might consolidate all your sales tax knowledge in another class. That
> way you have one source of responsibility for that behavior.
> Otherwise, if you added, changed or deleted a role, you'd have to
>
On Mon, Mar 2, 2009 at 10:34 PM, Stephen Eley wrote:
> On Tue, Mar 3, 2009 at 1:04 AM, Mark Wilden wrote:
>> user.role.invoices
>
> Heh. Which is what Zach said he wanted to do, and it isn't wrong.
Actually, I thought Zach was talking about a method on User called in_role.
> But it doesn't s
On Tue, Mar 3, 2009 at 1:04 AM, Mark Wilden wrote:
> On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote:
>
>> �...@invoices = Invoice.by_role(user)
>
> It doesn't seem right to me that invoices know about users and roles.
>
> I would try something like
> user.role.invoices
Heh. Which is what Z
On Mon, Mar 2, 2009 at 8:35 PM, Stephen Eley wrote:
> �...@invoices = Invoice.by_role(user)
It doesn't seem right to me that invoices know about users and roles.
I think of invoices are being closer to the metal -- closer to the
essence of the application -- than petty concerns like authorizatio
On Mon, Mar 2, 2009 at 11:35 PM, Stephen Eley wrote:
> On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote:
>>
>> Forgot to mention what we did do. We ended up with the following...
>>
>> def index
>> if user.has_role?("admin")
>>user.in_role("admin").invoices
>> elsif user.has_role?("associa
On Sat, Feb 28, 2009 at 5:26 PM, Chris Flipse wrote:
>
> Half of my problem right now is that I'm not even sure what layer to put
> model specific authentication! If it's in the controller layer, it's
> repeated logic in every controller that touches the model in question. If
> it's in the model
On Mon, Mar 2, 2009 at 5:16 PM, Zach Dennis wrote:
>
> Forgot to mention what we did do. We ended up with the following...
>
> def index
> if user.has_role?("admin")
> user.in_role("admin").invoices
> elsif user.has_role?("associate")
> user.in_role("associate").invoices
> else
> raise
On Mon, Mar 2, 2009 at 3:59 PM, James Byrne wrote:
> unknown wrote:
>
>>
>>> sam.authorized?(controller_or_model, action)?
>>
>> I'll suggest that it's the controllers who are responsible for telling
>> what role or other requirements need to be satisfied to get their
>> services, and that it's th
On Mon, Mar 2, 2009 at 4:50 PM, Zach Dennis wrote:
> On Mon, Mar 2, 2009 at 3:59 PM, James Byrne wrote:
>> unknown wrote:
>>
>>>
sam.authorized?(controller_or_model, action)?
>>>
>>> I'll suggest that it's the controllers who are responsible for telling
>>> what role or other requirements ne
unknown wrote:
>
>> sam.authorized?(controller_or_model, action)?
>
> I'll suggest that it's the controllers who are responsible for telling
> what role or other requirements need to be satisfied to get their
> services, and that it's the job of the user object (maybe by delegating
> to some
- Original Message
> From: James Byrne
> Mark Wilden wrote:
> > Actually, it's the other way around.
> >
> > http://www.pragprog.com/articles/tell-dont-ask
>
> I have read this article and it leaves me rather more confused than not.
That's the danger of oversimplification. Anoth
James Byrne wrote:
Is this a semantic confusion on my part? Should I consider that what I
do with x.exists? is tell the object to answer a question?
Consider...
if x.exists?
x.important_method()
else
# nothing!
end
Now lets upgrade the variable x. Sometimes it points to a thin
Mark Wilden wrote:
>
>
> Actually, it's the other way around.
>
> http://www.pragprog.com/articles/tell-dont-ask
Sigh...
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/li
Mark Wilden wrote:
>
> Actually, it's the other way around.
>
> http://www.pragprog.com/articles/tell-dont-ask
>
I have read this article and it leaves me rather more confused than not.
I gather that I am missing something fundamental. Consider that when I
write x.to_s I am telling the obje
James Byrne wrote:
>
> I am not sure that this is really "pollution". One of the things that
> was pointed out to me on the Ruby list when I first began transitioning
> to OO was the mantra "ask" don't "tell". It seems to me that in an OO
> authorization scheme one might properly ask the use
On Mon, Mar 2, 2009 at 10:39 AM, James Byrne wrote:
>
> I am not sure that this is really "pollution". One of the things that
> was pointed out to me on the Ruby list when I first began transitioning
> to OO was the mantra "ask" don't "tell".
Actually, it's the other way around.
http://www.prag
Andrew Premdas wrote:
> So given that the rules should be in the model then the question is
> which part of the model should have this responsibility and how do
> you call it.
> Three choices come to mind here
>
> 1) Place the rule inside User
> 2) Place the rule inside the affected model
> 3)
Personally I think this should be in the model layer. As you've pointed it
you get alot of repetition if its in the controller layer. But putting
business logic in the controller layer goes against the fundamentals of MVC,
and is a bit of a Rails anti-pattern (fat controller).
So given that the ru
On 28 Feb 2009, at 22:26, Chris Flipse wrote:
Yes! This is what I was trying (poorly) to get at.
Responsibility issues might be a large part of why it got factored
this way to begin with. The global is bad. Really bad, which is
why I'm trying to figure out something that works better.
On Sat, Feb 28, 2009 at 3:42 PM, Ben Mabey wrote:
> Chris Flipse wrote:
>
>> I've actually been okay with it at the unit testing / rspec level -- I've
>> had it stubbed as you describe for a while.
>>
>> The pain point came in as I was trying to setup data for Cucumber ...
>> Which, listening to
On Sat, Feb 28, 2009 at 4:34 PM, Zach Dennis wrote:
>
> Disclaimer, this entire post has to deal with model level
> authorization and a technique I've been using and evolving in Rails
> projects. It has nothing to do with your issue of global state for
> what User is logged in. Onto the fun stuff
On Sat, Feb 28, 2009 at 2:54 PM, Chris Flipse wrote:
> I've actually been okay with it at the unit testing / rspec level -- I've
> had it stubbed as you describe for a while.
>
> The pain point came in as I was trying to setup data for Cucumber ... Which,
> listening to my tests, tells me that the
Chris Flipse wrote:
I've actually been okay with it at the unit testing / rspec level --
I've had it stubbed as you describe for a while.
The pain point came in as I was trying to setup data for Cucumber ...
Which, listening to my tests, tells me that the current structure is
bad. I was more
I've actually been okay with it at the unit testing / rspec level -- I've
had it stubbed as you describe for a while.
The pain point came in as I was trying to setup data for Cucumber ... Which,
listening to my tests, tells me that the current structure is bad. I was
more curious to see how other
On Sat, Feb 28, 2009 at 12:51 PM, Chris Flipse wrote:
>
>
> On Sat, Feb 28, 2009 at 1:38 PM, David Chelimsky
> wrote:
>>
>> On Sat, Feb 28, 2009 at 11:52 AM, Chris Flipse wrote:
>> > I've been going back over some legacy code, backfilling tests, and I'm
>> > encountering something that is causin
On Sat, Feb 28, 2009 at 1:38 PM, David Chelimsky wrote:
> On Sat, Feb 28, 2009 at 11:52 AM, Chris Flipse wrote:
> > I've been going back over some legacy code, backfilling tests, and I'm
> > encountering something that is causing no small amount of pain. This is
> in
> > a mature Rails app, that
On Sat, Feb 28, 2009 at 11:52 AM, Chris Flipse wrote:
> I've been going back over some legacy code, backfilling tests, and I'm
> encountering something that is causing no small amount of pain. This is in
> a mature Rails app, that's lived and migrated from 1.1 through to 2.1, so
> there's a lot
I've been going back over some legacy code, backfilling tests, and I'm
encountering something that is causing no small amount of pain. This is in
a mature Rails app, that's lived and migrated from 1.1 through to 2.1, so
there's a lot of ancient cruft built up in the corners that I've been trying
33 matches
Mail list logo
