Still looking ... for a solution to the ZF factory puzzle.
Previously, we all discussed the use of factory patterns in the ZF, and
some of the complications that arise. Ideally, we should be able to
directly instantiate adapter/plugin instances or use a factory method
with IDEs helping complete code and catch our spelling errors for both
of these use cases.
http://www.nabble.com/forum/ViewPost.jtp?post=5824988&framed=y&skin=16154
In conclusion, no one has yet proposed a solution that fits the ideal
above. I've summarized various syntactical ways of working with
factories in PHP:
http://framework.zend.com/wiki/display/ZFDEV/Factories
Cheers,
Gavin
Andi Gutmans wrote:
We are looking for a generic solution that would apply to all the classes. I
think it's better to be consistent across the framework e.g Zend_Db,
Zend_Services_Google, Zend_Config (when possible), instead of reinventing
the wheel each time.
As to how to support code completion, the only way is to have people
instantiate concrete classes, e.g.:
$config = new Zend_Config_Ini("config.ini"...)
$db = new Zend_Db_MySQL(...)
$service = new Zend_Service_Google_Search(...)
There is a big advantage of this method as code completion in IDEs would
significantly assist developers both in code-completing the "long" names but
most important, code completing methods, properties and constants. I see a
lot of value in that...
This doesn't mean that we couldn't have a factory if/when needed. For Google
Services and Ini a factory probably would not be needed to often in real
life. For Db when many apps might allow the user to configure the data
source via GUI, it would make sense to make a factory available to the user.
My recommendation would be to expose concrete classes, e.g. go with KISS and
tooling friendly, but have a factory when that makes sense such as for DB.
As to the factory, I'm not a big fan of strings because tools can assist
that case, e.g. new Zend_Db("PDO_MYSQL",..). The problem though is that
class constants tend to be a bit too ugly in this case although they are
much friendlier. Another option would be to use global constants, e.g.
ZEND_DB_PDO_MYSQL to achieve
$db = new Zend_Db(ZEND_DB_PDO_MYSQL, ...)
Andi
-----Original Message-----
From: Matthew Ratzloff [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 17, 2006 10:25 AM
To: Zend Framework General
Subject: Re: [fw-general] Decision:
loadData('xml:/something/bar.xml'); vs. new Foo('/something/bar.xml');
More use cases and variants to consider:
const GOOGLE_TRANSLATE = "TRANSLATE";
const GOOGLE_SEARCH = "SEARCH";
$someService = new Zend_Service(GOOGLE_TRANSLATE,
''en','fr'); # code
completion works or $someService = new
Zend_Service('Google_Translate', ''en','fr'); or $someService = new
Zend_Service_Google('Translate', ''en','fr'); or $someService = new
Zend_Service_Google(TRANSLATE, ''en','fr'); # code
completion works or
$someService = new Zend_Service_Google_Translate('en','fr'); # code
completion works
By process of elimination:
You've got to consider that not all service classes will be
included in the core (some will be user created, etc.), so
Zend_Service as a factory class is out. So that means the
first two options aren't viable.
Zend_Service_Google_Translate is simply too long for a class name.
Actually, I'd prefer it to look something like this:
$google = new Zend_Service_Google($license); $french =
$google->translate($english, "en", "fr"); $results =
$google->search($string); foreach($results as $result) { ... }
Have Zend_Service_Google handle the interface between itself
and Zend_Service_Google_Translate (caching objects as necessary).
-Matt
