This is something that's been bugging me for a while, but really manifested itself while working with the code for singleton models. That is, the whole point of the (Singleton)Model class is to provide a hook into the framework by way of the Context object, essentially coupling the model to the framework. What bugs me is, what necessitates this?
It seems to me that a model that knows how to use the Context object knows too much about the internals of the framework and is thereby devalued. The model should be a reusable piece of code that works in a very specific niche. Once I start using the Context object from within my model, it looses most if not all it's reusability and can no longer be used outside the scope of Agavi. If things change in the internals of Agavi, they have greater potential of breaking my models because my model's hands are in the cookie jar so to speak. :) Hopefully that's enough detail to understand why this coupling creates a more fragile environment. So how do our models get what they need? We give it to them, it's the controller's job to push and pull data between the model and view, after all. Dont expect the model to help itself to our internals. If the problem domain involves a db, we pass the model the db. If the problem domain involves people, we pass it people. If the problem domain involves arbitrary sets of aggregate data, we... etc. This brings us right back to the __construct() vs initialize() topic. Controller::get*Model() methods are convenient methods for finding and instantiating a class, but they assume our class has extended the *Model classes and calls the initialize method passing the Context object as a parameter. I changed it in the david_singleton-model branch so that it will only call the initialize method if it exists, so we dont _require_ the models we use to couple themselves to the framework. I guess we could just continue down this same path, and advocate models not _require_ parameters be passed into their constructors... *shrug* -Mike _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
