> -----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
