Not sure if I agree. I feel that what you describe sounds more like a generic helper library. Why not just use a decoupled library you can use across all platforms, frameworks and projects, and then write a small model that isn't much more than a wrapper? Personally, I find it quite useful to have the context in the model. But then, there's no real need for it since I can get the context or controller by calling getInstance() on these. In my eyes, it is not exactly a fragile construct either. After all, you know what you're doing when writing a model, and you can easily achieve reusability by wrapping a library.
The parameter passing question is a good one. If we decide to decouple models entirely, they definitely need those params so we can pass in the stuff we desire. But until that happens, I'm not even sure they need any parameters passed in - you can just as well create methods to set what you need after retrieving the instance. But with models decoupled, it will be possible to use virtually any external library and fetch it using get*Model(), so we'd need constructor arguments there. I'm not sure, to be honest. What do the others think? - David > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mike Vincent > Sent: Thursday, July 28, 2005 8:21 PM > To: Agavi Development > Subject: [agavi-dev] (Singleton)Models,and Passing Args... aka > __construct() vs initialize() redux > > 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 _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
