If the answer is no, or it is such that I need to make use of a model loaded through the Controller’s uses array then I place the logic in the controller. The cutoff point for me is that if I ever would need to App::import a model into another model then I should be moving the logic to a controller.

@Tim Daldini I generally write my custom model functions to accept the same options array as the internal function I would be using anyways ( the array passed to find, read, etc ) and simply set the defaults I generally need in the function declaration. Then you can simply call it for the default common needs, or pass an options array in. Depending on your needs sometimes processing the options is more code than fetching, tweaking and returning the data but it does leave things flexible.

Yes, it is difficult to foresee how an application will change over time. So you always have to write code that’s clean and easy to change (I know, it is easier said than done, and unfortunately you often learn only at the time when you have to make a change that your solution wasn’t that good…).

@Abba: Ah, yes, that’s a better example. And it’s true that there is not much talk about callbacks. I guess it is because they aren’t used often. If I look at my own code, the only callback I often use is Controller::beforeFilter(), I almost never use the other callbacks.

@Stephen: Strange, sounds like a bug to me. Maybe it helps as a workaround to manually instantiate your model like $this>Product = new Product(); ?

I just proved this by creating a controller in my main application which calls the function. This works, instead of passing through to the SQL.

I have an ecommerce site built using Cake, and it’s gotten to the point where I’m fine-tuning the admin backend, which I’ve built as a plugin.

I’m trying to fatten up my models now to remove some of the complexity from my controllers – but I’m unable to call any of the functions I’m writing – the call just gets passed directly through to MySQL and so fails.

As an example, I’m trying to do:
$this->Product->findMostPopular();

Instead of calling the Product::findMostPopular() method, it’s directly executing findMostPopular as SQL.

Could this be because I’m referring to main app models from my plugin?

Bleh, my original point is that amidst all of this Fat Models discussion there has been very little posted on the usage of the controller / model callbacks system outside of the few behavior authors.

Later you notice you need to change 2 of those calls. One should use an extra condition, and another should fetch different fields…what do you do in such case? You could add extra optional field and condition arguments but in the end I think it would make things possibly harder to read because you might customize several of model methods in different ways as you develop your application…and you sometimes need to remember why and how you changed things.

Because it is sometimes hard to foresee how your application will change (and also, I hate switching between multiple files…) I mostly don’t use this technique. I personally think using standard model methods are very readable once you are familiar with them.

But I guess that’s just me…

@Thomas, henrique: If you look at the design of the model class I doubt it was intended to be used in that way, at least it doesn’t force you to write fat models.

@Kalileo: Yes, refactoring is always a good thing to do. When I refactor stuff I usually end up with some private methods, and the AppModels stay rather skinny. But this is probably application-specific.

@Yevgeny: Yes, that’s true, model code is much easier to test than controller code.

@Dave: Yes, that’s something you always have to ask yourself when writing code (not only when writing models).

@Jelle: To me your scenario sounds like it would make sense to have special methods like saveAsDraft(), saveAsSent(), etc. But it could also make sense to create models for your states, it depends on your requirements.

@Abba: Hm, I wouldn’t create the Profile in the afterSave() callback function. I would rather create it at the place where the User is saved, so that you see those two “actions” are connected.

My quest is to find a way to separate “pagination logic” (an put it in the controller) from “bussines logic” (an put it in the model), and pass necesary data to limit the model results.

In my current project model’s find methos have to deal with complex conditions based on user profile, object status, dates… So model encapsulation makes sense.