Comments on: A missing concept: model “components”

By: Garret

Garret — Sun, 25 May 2008 23:31:40 +0000

> I agree: if we already have Helpers and Components, why not
> have something similar for Models. Behaviors add a *behavior* to
> the model, i.e. responsibilities to that model. What if we want
> utility classes ?

@XR: EXACTLY

By: cakebaker

cakebaker — Wed, 21 May 2008 17:42:11 +0000

@Xr: Thanks for your comment, you worded it much better than I did ;-)

By: Xr

Xr — Wed, 21 May 2008 06:28:39 +0000

the_woodsman: The interface forces you to implement some methods, it doesn’t give a shared implementation but a shared API. Not what we’re after, if I understood correctly.
Still, it is indeed of good practice in OOP to separate concerns.

I agree: if we already have Helpers and Components, why not have something similar for Models. Behaviors add a *behavior* to the model, i.e. responsibilities to that model. What if we want utility classes ?

By: cakebaker

cakebaker — Sun, 18 May 2008 08:30:45 +0000

@Felix: A simple example: a method to format data (e.g. a date) in a certain way. But in principle you can take any method you make private in your model as a potential use case.

@the_woodsman: Yes, it is the same principle, only in a different context.

Hm, I don’t understand your idea with the interface :| With an interface you define a public API, so I don’t see how you could hide something by using an interface.

By: the_woodsman

the_woodsman — Sun, 18 May 2008 01:12:28 +0000

> However, adding shared functionality
> between models
> but hiding it from your controllers
> makes little to know sense.

Erm, isn’t this akin to a protected method/field in a parent class?
If it’s a core part of OO languages, I think it’s probably a good idea: it makes good sense to only expose a well chosen public API.

PHP doesn’t support multiple inheritence, so as mentioned, a composition pattern is essential to the whole concept.

Could you not achieve similar using an interface (PHP5 only, so not for the cake core obv), i.e your models implement the interfaces, and your controllers can check if they have?

By: Felix Geisendörfer

Felix Geisendörfer — Sat, 17 May 2008 16:28:18 +0000

Daniel: I don’t get it. I see the problem with all behaviors affecting the Model API, but that can easily be worked around by Overloading your behavior, and making its instance available to your Model during the setup process and then dispatching calls on it to private methods inside your behavior. However, adding shared functionality between models but hiding it from your controllers makes little to know sense. Do you have an actual usage case for that?

By: cakebaker

cakebaker — Sat, 17 May 2008 07:51:43 +0000

@Mariano: I’m not sure you understand what I want to accomplish. I want to share model functionality between models without making the shared functionality available for controllers. If I add a (public) method to a behavior, then I can access it from models *and* controllers. If I make this method protected or private, I can access it neither from models nor controllers. You see the problem?

@Garret: Thanks for your long comment and the clarifications!

I have chosen the name “model components” to show it is a very similar concept to the concept of “controller components”. But maybe it would be better to use a different name…

Yes, you are right, I’m looking for the best most elegant way to do it, and not for a workaround to accomplish (almost) the same.

The same here, I don’t like to mess with the structure of the cake core, and so I keep using the solution with the “vendors” folder. And yes, it would be cool to have it implemented in the core :)

By: Mariano Iglesias

Mariano Iglesias — Fri, 16 May 2008 13:00:15 +0000

@Garrett: I don’t get it, did you read the comments? What are behaviors then??

By: Garret

Garret — Fri, 16 May 2008 00:42:57 +0000

hmm, your input filter removed some of my example code

By: Garret

Garret — Fri, 16 May 2008 00:40:40 +0000

Well I for one agree with you.

I’ve been in many situations where I wished there were components available to load into your model just as easily as you can for controllers. You don’t necessarily even have to call them components, you could call them, say, extensions, processors, plugins? I dunno, something that indicates that they’re not part of the actual model, but will work inside the model for processing purposes and is protected from outside forces i.e. the controller and view.

I don’t think you’re trying to understand how to get it to work, as I know you probably understand completely how to import files and/or use Snook’s class inheritance solution. You’re looking for the best most elegant way to do it, and I think you’ve hit it on the head.

Putting everything in AppModel is definitely dirty. I also think Snook’s solution is dirty, he says so himself, and can get very complicated very quickly if you have a large model structure. It would be easier if you could just load a component into your model, just like you can controllers.

Example:

Component->action($this->data);
…

}
?>

(I know this is a bit of a reiteration of what you wrote, it just adds a little bit for clarity)

So, anyways, I think you’re right, and I don’t want to mess with the structure of the cake core too much since I like being able to keep current for bug fixes, so I kind of have to live with it for now. However, I think it would be fantastic if this were implemented in the core.