-- Matthew Ratzloff m...@builtfromsource.com wrote
(on Saturday, 17 January 2009, 12:14 PM -0800):
Since configuration is such a fundamental aspect of most components, perhaps
this can be added to the coding standards, along with whatever suggested
implementations the community agrees upon?
-- Matthew Ratzloff m...@builtfromsource.com wrote
(on Friday, 16 January 2009, 09:42 AM -0800):
This is more or less how you see the setOptions() implementation in a few
classes currently. The idea that you proxy the key to a mutator (setter)
setSomething($value) method.
Since configuration is such a fundamental aspect of most components, perhaps
this can be added to the coding standards, along with whatever suggested
implementations the community agrees upon?
-Matt
On Sat, Jan 17, 2009 at 6:55 AM, Matthew Weier O'Phinney
matt...@zend.comwrote:
-- Matthew
The primary problem with configuration in Zend Framework is that configuration
is left up to each class and so each class handles it differently. The
primary problem with PHP is lack of mixins, which would elegantly solve the
first problem. I solved the issue at my job like this:
The
This is more or less how you see the setOptions() implementation in a few
classes currently. The idea that you proxy the key to a mutator (setter)
setSomething($value) method.
Yep, except it's in one place instead of several with tiny variations. And
it works with static setters.
-Matt
On Jan 13, 2009, at 10:55 , Ralph Schindler wrote:
First, the __construct($options = array()) {} convention for the most
forward facing component API constructor adds a level of consistency
that
makes each and every component look and feel similar in style. This
would
makes it easy to
I've been pushing the setOptions/setConfig paradigm for a while, and it
works really well with DI. Your constructor then passes the options on
to setOptions() which attempts to call setters named after the keys. The
result is that it allows you to push your dependencies in at
instantiation
Comments inline:
The better solution is dependency injection, and one facet of this is removing
I disagree (if you are talking about DI as a container model)
explicit references to Registry/global items from source code. This is a
I agree.
feature the ZF has yet to include but Bradley
great post ralph! this is a step into a brighter future ;-D
my two cents though.
1. having __construct(array $options); is cool from a simplicity point but it
hides dependencies, since in an array you couldinclude ANYTHING. Most
components also don't require the dependencies to be set in
-- Benjamin Eberlei kont...@beberlei.de wrote
(on Tuesday, 13 January 2009, 06:11 PM +0100):
great post ralph! this is a step into a brighter future ;-D
my two cents though.
1. having __construct(array $options); is cool from a simplicity point but it
hides dependencies, since in an array
Hello matthew,
i would subscribe to such a component based registry thing :-)
ok its not up to me, but i think its a very good mixture
between DI and simplicity and especially the Controller component
would really benefit from the more flexibility. :-)
On Tue, 13 Jan 2009 16:38:48 -0500,
Hi Matthew,
Yes, we've had this discussion before. :) When I wrote the first edition
of the book I believe it was a good practice. Now however, I believe that
there are better ways to accomplish the goals of Globals.php.
The goals of Globals.php were 2 fold.
1) A central repository for
the registry is global too and it has no type checking, which makes a
global
class that has setter and getter for specific types winner over a
general registry in my opinion.
static classes that contain objects and are used inside dynamic objects are
always
an obstacle to testing, singletons
Subject: Re: [fw-general] Is Cal Evan's Globals.php a recommended approach
the registry is global too and it has no type checking, which makes a
global
class that has setter and getter for specific types winner over a
general registry in my opinion.
static classes that contain objects and are used
Zend_Registry (http://framework.zend.com/manual/en/zend.registry.html) is a
container for storing objects and values in the application space. By storing
the value in the registry, the same object is always available throughout your
application. This mechanism is an alternative to using global
Eh, That's not really what he meant.
You (the original poster) may want to take a look at the proposal that is in the works for
Zend_Application. http://framework.zend.com/wiki/display/ZFPROP/Zend_Application+-+Ben+Scholzen
I have been using a Bootstrap/Application class in a couple of
-- swilhelm st...@studio831.com wrote
(on Friday, 09 January 2009, 12:26 PM -0800):
I have been Reading Cal Evan's Guide to Zend Framework Programming.
In it he describes a Globals.php file for creating a single class to
encapsulate access to global resources like the database connection,
17 matches
Mail list logo
