Bear in mind, I am not offering these thoughts up for any type of
immediate inclusion to the framework, just something to consider in part
with the config argument as it will come up as more complete modules for
using in ZF enabled applications will emerge.
By itself, Zend_Db neither provides nor encourages a method of
transporting adapters to consuming classes/objects. This means that
developers will resort to using their own solution bubbling up from the
bootstrap, which, generally speaking, will be a global registry. While
that works fine, I see two issues with that methodology. 1) You have an
instance of a Zend_Db_Adapter_Abstract in the same "container" as a
Zend_Config, Zend_Auth objects, and so on. 2) There is no convention for
where to "find" the default adapter from a module's perspective. By
this I mean, one module might require the dbAdater to exist at one
specific key in the global registry, whereas, another module might
expect to find the dbAdapter at a completely different key in the registry.
Furthermore, the only method for "pulling" a preconfigured adapter from
a structured place is the following:
$dbAdapter = Zend_Db_Table_Abstract::getDefaultAdapter();
Even this assumes that you have at least set an adapter for use by
Zend_Db_Table.
Most importantly, remember who the audience is and where they are coming
from. When you look at the landscape of php4/oo programmers coming over
to php5, in just about all cases, the first REAL need they had (and the
one solid example most books point out), was to solve the problem of
singular db adapter across modular code (ridding of random connect
calls). The answer to that problem was the singleton.
To bring this back full circle to the config discussion, you are
proposing two options at current. Make the credentials for creating an
adapter GLOBAL so that modules can create an instance from the factory,
OR require the developer to create an adapter and put it in the GLOBAL
registry at a place that I (as a module) require. The idea of a
singleton dbAdapter existing in a known location does not exist in this
framework yet.
Perhaps Zend_Db needs Zend_Db::getDefaultAdapter() ?
-ralph
Andi Gutmans wrote:
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
