Do you envision an application to have more than one DB connection that's shared among plug-ins? My guess is that there'd be one default one, and components which don't use that would define their own. Obviously everything is possible but I'm saying this based on other PHP apps I've seen.
Andi > -----Original Message----- > From: Ralph Schindler [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 26, 2007 10:47 AM > To: Bill Karwin > Cc: Zend Framework General > Subject: Re: [fw-general] Config-driven framework components > > Inline below: > > Bill Karwin wrote: > >> -----Original Message----- > >> From: Ralph Schindler [mailto:[EMAIL PROTECTED] > >> factory(Zend_Config $config); factory(string $type, Array $args); > >> factory(string $type, Zend_Config $args); > > > > Yes, I agree with that. It's no problem to code it. > > > > Awesome, is this something we can put in jira as a future > improvement now? or should round out the config discussion? > > > Anyway, I'm not sure why we need a new class for this. Why > can't one > > do it in the following way? I tried it, and this works with the > > current classes. You can create a new Zend_Registry object > and store > > it as a value in the singleton registry. > > > > $db = Zend_Db::factory(...); > > $dbRegistry = new Zend_Registry(); > > $dbRegistry->default = $dbRegistry->blog = $db; > > Zend_Registry::set('db', $dbRegistry); > > > > Then access db adapters later in your app: > > > > $db = Zend_Registry::get('db')->blog; > > Of course that way works! It is php after all ;) > > 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. > > The difference is in requirements. Say I write a module for > using in ZF enabled applications called 'The ZFPublish > module'. And Matthew writes a module called 'The ZFWiki > module'. Both modules aim at being a drop in an config to > work type of application. Very little code is needed. > > Both modules need a db adapter. > > Without a db registry, there is not gonna be a standard > convention as to where to find a database adapter, named or > not. My module might call for the usage of a db registry > (created by the user) or worse, a global registry (created by > the user). Since I am offloading the creation of a registry > to the user in both cases, I cannot say with any certainty > that other modules, like matthews will be using the same 'db' > named registry. > Perhaps he might call his 'dbAdapter'. In which case, now > the user has to create two registries that solve the same > problem. Sounds a bit like its not adhering to DRY principals. > > 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. > > In both cases, having a Zend_Db_Registry allows us to not > require the user to create the actual 'container' and can > only have to worry about whats actually in the container. > > As a module writer, I don't have to go out and 'create a > convention', nor do I have to know what Matthew is working > on, and ask him if my conventions will play with his > conventions for those people that want to use zfWiki and > zfPublish in the same site. > > Sorry, the 2 cents got inflated to about 5 cents ;) > > Regards, > Ralph > > > > >
