Exactly my thought... :)
> -----Original Message----- > From: Bill Karwin [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 26, 2007 11:55 AM > To: Zend Framework General > Subject: RE: [fw-general] Config-driven framework components > > > -----Original Message----- > > From: Ralph Schindler [mailto:[EMAIL PROTECTED] Awesome, is this > > something we can put in jira as a future improvement now? or should > > round out the config discussion? > > Ok, I've put the issue in here so we can track it: > http://framework.zend.com/issues/browse/ZF-1775 > > > But in the long run (for the goal of creating portable modules that > > need little to no configuration to work inside a zf enabled > > application), offloading the "container" creation to the developer > > introduces more complexities that could be taken care of in Zend_Db > > itself. > > Should it really be taken care of in Zend_Db? Zend_Db is for > accessing databases. Overloading it with application > configuration details doesn't seem like good cohesion. > > > If there were a Db Registry, my module might be able to look for a > > 'blog' name key'ed adapter, then perhaps fallback on the 'default' > > adapter. In Matthew's module, he will be able to look > for > > the zfWiki key'd db adapter, and fallback on the 'default' adapter. > > It has to be a documented convention either way. Why > wouldn't a given module use 'standard' or 'dflt' or '_' as > the fallback adapter? If it's documented, then there's no > reason why we couldn't document standard usage of > Zend_Registry, e.g. 'database' is the recommended standard > key to store a registry object that contains db adapter > objects? Likewise for other application resources like > 'log', 'cache', 'http', etc. > > I'm trying to look for ways we can use the existing classes, > and avoid creating more classes, more singletons and more > static methods. > > Regards, > Bill Karwin >
