I was agreeing! I wasn't saying that what you were saying there wasn't
expressing the intent in the model, I was saying that my long ramble was
saying the same thing roughly, and that this differs from the standard
approach in rails of using ActiveRecord:Base class methods directly.
Apologies for
"Andrew Premdas" writes:
> 2008/12/11 Pat Maddox writes
>> The clearest way to represent these contextual differences, in my
>> experience, is to create an intention-revealing method and use that.
>
> The point I'm making is that this intention should be expressed
> clearly in the model, whereas
yeah, instead of using Post.find(:all) in your controller, use a method like
Post.all_posts, or some names like that. Then in the controller spec, you
go:
Post.should_receive(:all_posts) and leave the implementation detail of this
method to the Post model. Technically speaking, this all_posts more
Looking at generated controller specs we tend to get something like
describe PostsController do
describe "handling GET /posts" do
before(:each) do
@post = mock_model(Post)
Post.stub!(:find).and_return([...@post])
end
def do_get
get :index
end
...
it "
2008/12/11 Pat Maddox writes
> "Andrew Premdas" writes:
>
> > Pat,
> >
> > Thanks for reply. The one year ago thing was a really bad
> > example. Using your terminilogy it looks like a rule that changes what
> > my app does. But I was talking about a change in what the app is;
> > i.e. a busines
"Andrew Premdas" writes:
> Pat,
>
> Thanks for reply. The one year ago thing was a really bad
> example. Using your terminilogy it looks like a rule that changes what
> my app does. But I was talking about a change in what the app is;
> i.e. a business rule.
>
> I definitely don't want to have bu
"Andrew Premdas" writes:
> We're actually getting pretty close to saying the same thing here, though my
> use of language is causing some confusion. The two sorts of
> requests I was talking about where a view request and a request by the
> business for a specific rule to be implemented.
>
> If
We're actually getting pretty close to saying the same thing here, though my
use of language is causing some confusion. The two sorts of requests I was
talking about where a view request and a request by the business for a
specific rule to be implemented.
If there were AuditablePosts the controlle
Pat,
Thanks for reply. The one year ago thing was a really bad example. Using
your terminilogy it looks like a rule that changes what my app does. But I
was talking about a change in what the app is; i.e. a business rule.
I definitely don't want to have business rules in controllers. From my
vie
On Thu, Dec 11, 2008 at 11:28 AM, Andrew Premdas wrote:
> As you say controllers should not be responsible for defining things, but
> in Rails this is exactly what they do, they formulate queries using class
> methods like find_by_xxx. Personally I think Rails is somewhat confused or
> perhaps l
Mark,
Thanks for your reply. As you say controllers should not be responsible for
defining things, but in Rails this is exactly what they do, they formulate
queries using class methods like find_by_xxx. Personally I think Rails is
somewhat confused or perhaps lax in defining Controller responsibil
"Mark Wilden" writes:
> On Thu, Dec 11, 2008 at 4:33 AM, Andrew Premdas wrote:
>
> it "should find all posts" do
> Post.should_receive(:find).with(:all).and_return([...@post])
> do_get
> end
>
> Now this last spec "should find
On Thu, Dec 11, 2008 at 4:33 AM, Andrew Premdas <[EMAIL PROTECTED]> wrote:
>
>> it "should find all posts" do
>> Post.should_receive(:find).with(:all).and_return([EMAIL PROTECTED])
>> do_get
>> end
>>
>> Now this last spec "should find all posts" is nosy is far as I'm concerned
Looking at this a bit further, it seems in Rails controllers decide how
things are got from Models i.e. by calling a class Method. I sort of forgot
this for a bit. So with this pattern the testing is correct in reflecting
the design of Rails. Still, with my OO purist hat on, it feels like this
resp
14 matches
Mail list logo
