| SitePoint Sponsor |
Hi,
I've ported some parts of PicoContainer to PHP5.
It allows you to have a main container that will resolve the dependencies of your different objects.
It is a good alternative to singletons
The code is still at my work, but I'm going to post it tomorrow..
Cheers,
zimba
Like promised, even if it didn't generated as much reaction as I expected, here is the code :
Look, here is how you'd use it :PHP Code:<?php
/*\
* Created on 6 janv. 2005 by Jonas Pfenniger <zimba.tm@gmail.com>
\*/
class DiContainer_Default
{
private
$components = array(),
$instances = array(),
$parent_container = null;
function __construct($container = null)
{
if ($container !== null)
{
$this->parent_container = $container;
}
}
/**
* @todo Method doc
*/
function registerComponent($class_name)
{
$args = func_get_args();
array_shift($args);
$this->components[$class_name] = $args;
}
/**
* Use on last resort
*/
function registerInstance($class_name, $object)
{
$this->instances[$class_name] = $object;
}
function getComponentInstance($class_name)
{
// Container has component
if ($this->instances[$class_name])
{
return $this->instances[$class_name];
}
elseif (array_key_exists($class_name, $this->components))
{
// Create instance if not exists
$args =& $this->components[$class_name];
$refl_class = new ReflectionClass($class_name);
try
{
$construct = $refl_class->getMethod('__construct');
$params = $construct->getParameters();
for($i = 0; $i < count($params); $i++)
{
if ($params[$i]->getClass())
{
// Recursion power
$args[$i] = $this->getComponentInstance($args[$i]);
}
}
} catch(Exception $e) { echo "glups:" . $e->getMessage(); }
// Create class
$c = 'return new '.$class_name.'(';
for($i=0; $i<count($args); $i++)
{
$c .= '$args['.$i.']';
if ($i < count($args) - 1) $c .= ',';
}
$c .= ');';
//echo $c;
$this->instances[$class_name] = eval($c);
return $this->instances[$class_name];
}
elseif ($this->parent_container !== null) // ask parent
{
return $this->parent_container->getComponentInstance($class_name);
}
trigger_error("Component $class_name is not registered", E_USER_ERROR);
}
// TODO : function start, LifeCycle
function start()
{
}
// Add class loader
}
?>
DI describes the relation between the different objects.PHP Code:<?php
/*\
* Created on 7 janv. 2005 by Jonas Pfenniger <zimba.tm@gmail.com>
\*/
class Boy {
function __construct() { }
public function kiss(&$kisser) {
if (is_object($kisser))
echo "I was kissed by " + get_class($kisser);
else
print_r($kisser);
}
}
class Girl {
private $boy = null;
function __construct(Boy $boy) {
$this->boy = $boy;
}
function kissSomeone() {
$this->boy->kiss($this);
}
}
$x = new DiContainer_Default();
$x->registerComponent("Girl", "Boy");
$x->registerComponent("Boy");
$a = $x->getComponentInstance("Girl");
$a->kissSomeone();
?>
For more concrete examples, I'm currently implementing the MVC pattern and you'll be able to see how any class of the framework will be substituable.
Let me know what you thinks
I was actually looking at this idea a while back through Fowlers article.
Although I didn't get around to it, it was still on my TODO list.
I will be interested in seeing the final product.
The biggest problem actually is this part :
Because it's around 20 times slower than normal instanciation :/PHP Code:// Create class
$c = 'return new '.$class_name.'(';
for($i=0; $i<count($args); $i++)
{
$c .= '$args['.$i.']';
if ($i < count($args) - 1) $c .= ',';
}
$c .= ');';
The TODO things are :
- Guessing instanciation of unregistered components
- LifeCycle
- Checks for instanciation loops (A->B->A->...)
From from the 2 minutes Tutorial of pico container, shouldn't it be
andPHP Code:$x = new DiContainer_Default();
$x->registerComponent("Girl"); //only Girl class
$x->registerComponent("Boy");
$a = $x->getComponentInstance("Girl");
$a->kissSomeone();
andPHP Code:echo "I was kissed by " . get_class($kisser); // dot notation for str cat
PHP Code:if (isset($this->instances[$class_name])) // check using isset
Wei.
Hey Zimba,
I couldnt resist tackling one of your TODO items. Did some refactoring and wrote some tests(attached). I cant figure out a way around eval'ing the constructorbut interfaces are now supported.
There may be a port of pico coming anyway : http://docs.codehaus.org/display/PICO/Ports , so you may want to contact them before you do much work.
PHP Code:class Container {
private $components = array();
public function registerComponentImplementation($className) {
$this->components[$className] = $className;
$reflectionClass = new ReflectionClass($className);
$interfaces = $reflectionClass->getInterfaces();
foreach($interfaces as $interface) {
$this->components[$interface->getName()] = $className;
}
}
public function getComponentInstance($className) {
if(array_key_exists($className, $this->components)) {
$component = $this->components[$className];
$reflectionClass = new NewReflectionClass($component);
$constructorMethod = $reflectionClass->getConstructor();
$constructorParameters = $constructorMethod->getParameters();
return $this->createInstance($component,
$constructorParameters);
}
trigger_error('Unknown Component Instance');
}
private function createInstance($className, $constructorParameters) {
$paramInstances = array();
$evalStatement = array();
foreach($constructorParameters as $index => $constructorParameter) {
$parameterClass = $constructorParameter->getClass();
$parameterClassName = $parameterClass->getName();
$paramInstances[] = $this->getComponentInstance($parameterClassName);
$evalStatement[] = '$paramInstances[' . $index . ']';
}
return eval('return new ' . $className .
'(' . implode(',',$evalStatement) . ');');
}
}
class NewReflectionClass extends ReflectionClass {
public function getConstructor() {
foreach($this->getMethods() as $method) {
if($this->isConstructor($method)) {
return $method;
}
}
return new NullReflectionMethod();
}
private function isConstructor($method) {
return ($method->getName() == '__construct' ||
$method->getName() == $this->getName());
}
}
class NullReflectionMethod {
public function getParameters() {
return array();
}
}
It looks like Sebastian Bergmann (http://www.sebastian-bergmann.de/blog/) was working on a port but isnt any more. There is another guy who may have done some work however:
http://comments.gmane.org/gmane.comp...ner.devel/4025
EDIT:
This may be slightly better?Originally Posted by Brenden Vickery
I cant figure out a way around eval'ing the constructor
PHP Code:$functionCode = 'return new ' . $className .
'(' . implode(',',$evalStatement) . ');';
$function = create_function('$paramInstances', $functionCode);
return $function($paramInstances);
Last edited by Brenden Vickery; Jan 20, 2005 at 02:55.
Hi all,
Yes, I've done a lot of work, I think 1/2 of oryginal code is ported to PHP5, all with tests (TDD), oryginal class / interfaces names and so on.
Please, contact me (pawel.kozlowski@gmail.com) for details. We could join effors and hava Pico for PHP!!!
Best regards,
Pawel Kozlowsi
Wow, I love contributions !Hey Zimba,
I couldnt resist tackling one of your TODO items. Did some refactoring and wrote some tests(attached). I cant figure out a way around eval'ing the constructor
It's the first time I ever had one (and that I posted something also)
Why don't we start a page to put all this together ?
Btw, instead of constructing the "new Class($param1, $param2, ...)" each time,
we could imagine a generation/caching technique.
The container generates a file :
The file name is the hash of implode(array_keys($this->components)); so next time it can be found back.PHP Code:<?php
$this->components['Boy'] = new Boy();
$this->components['Girl'] = new Girl($this->components['Boy']);
?>
In Pico this is a done by havin special ComponentAdapter (You have omited this part of Pico in Your port). It's name is CachingComponentAdapter. I love design of this part of Pico. It's very clean and could be the same in PHP5. As I don't think we should port every class 1:1, I think we could benefit alot by looking at the oryginal design and the source code.Wow, I love contributions !
It's the first time I ever had one (and that I posted something also
Why don't we start a page to put all this together ?
Btw, instead of constructing the "new Class($param1, $param2, ...)" each time,
we could imagine a generation/caching technique.
Best regards,
Pawel Kozlowski
Hi,
Zimba, I’ve walked through Your code, and there are some remarks:
“my implementation doesn't support the parameters like Pico”
actually, Your implementation doesn’t support auto-wiring. That is, Your should be able to put 2 components into the container (like Boy and Girl). Now, if You’re taking Girl from the container it should find out that the Girl needs a Boy. After that, container can figure out that there is only one class (or interface) Boy matching constructor params in the Girl class. From there it’s a straight way to auto-wire (inject) the instance of Boy into Girl’s constructor. We can of course use params to give container a hint about what to inject into class constructor (it’s useful if we have 2 instances of Boy). But this param should only indicate particular instance, not a class or a interface. Those dependences could be resolved by a container.
„TODO:
- Guessing instanciation of unregistered components
- LifeCycle
”
Could You explain what You mean by „Guessing instanciation of unregistered components”? If a component is unregistered with a container, Pico has no chance to know about this component. From my point of view there is nothing to guess here.
OK, another story is a set of features that make sense in PHP. I think there is no reason in implementing LifeCycle. Same with containers hierarchy. There are good reason for those features in Java, but I think they are of little value in the PHP world.
This all leads me to question: “Why the hell use IoC containers in PHP”? I can think of couple of reasons:
- We can have one, consistent way for creating so-called singletons
- IoC leads to a cleaner, reusable code (no more globals, right?)
- As a “side effect” we can have “lazy include”, as we can include class files just before they are going to be used
But another questions starts to pop out of my head: “What to inject in PHP”??? My first thought was: “DBConnection object into DAO”. OK, but what about DAO? Should I inject them into Action classes? This way I have to register every DAO and Action class with a container.
Ok guys, if you are serious about porting Pico to PHP I think we should:
- agree if we really (!) need it for PHP. Where we can use it?
- decide what part of a original functionality should be ported,
- walk carefully through the original code. I’ve spend hours digging through the Java version of Pico and I find it’s design very clear and very smart.
Hmm, not sure how well this will work in PHP. I'm totally a Java nut now and use the Spring framework which like Pico is an IoC container featuring DI and much more. Dependency Injection works well with Java due to the lifecycle of a webapp. Spring uses a bean factory where you create xml configuration files to define your beans and the dependencies so it can figure out what to inject when the webapp first starts up. Beans can be daos, web controllers, forms, validators, data source, etc.
For peeps that want to see how this works in Spring this is a small example. This is a snippet from an xml file for creating 4 beans: JNDI dataSource, sqlMap, userDAO and an Acegi password authentication bean.
This is what the start of my UserAuthenticationImpl looks like.Code:<bean id="passwordAuthentication" class="org.kuato.mutant.auth.UserAuthenticationImpl"> <property name="userDao"><ref bean="userDao"/></property> </bean> <bean id="userDao" class="org.kuato.mutant.dao.ibatis.UserDaoImpl"> <property name="dataSource"> <ref bean="dataSource"/> </property> <property name="sqlMap"> <ref bean="sqlMap"/> </property> </bean> <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"> <value>java:comp/env/jdbc/mutant_postgres</value> </property> </bean> <bean id="sqlMap" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean"> <property name="configLocation"> <value>WEB-INF/classes/sqlmaps/SqlMapConfig.xml</value> </property> <property name="dataSource"> <ref bean="dataSource"/> </property> </bean>
Spring looks at the xml configuration file and knows that after it creates the dataSource it injects it into the sqlMap. Then it injects those two into the userDao and finally injects the userDao into the passwordAuthentication bean. All you have to do is provide the settor methods or you can use constructor injection also.Code:public class UserAuthenticationImpl implements PasswordAuthenticationDao { protected final Log logger = LogFactory.getLog(getClass()); private IUserDao userDao = null; public void setUserDao(IUserDao userDao) { this.userDao = userDao; } public UserDetails loadUserByUsernameAndPassword(String username, String password) throws DataAccessException, BadCredentialsException { User user = this.userDao.selectUserByUsernameAndPassword(username, password); this.logger.info("user= " + user); if (user != null) { // read in the roles and do other things List roles = this.userDao.assignedRoles(user.getUserId()); GrantedAuthority[] authorities = new GrantedAuthority[roles.size()]; for( Iterator it = roles.iterator(); it.hasNext(); ) { ... // read the roles and assign to Acegi authorities array } } else { throw new BadCredentialsException("Bad Credentials Presented"); } .....
Keep in mind, 4 beans are being created here that will live till the webapp is restarted: dataSource, sqlMap, userDao, passwordAuthentication. When you add in all the daos, web controllers, form and validator beans you end up with quite a load of these beans being created by the container. Not a problem with Java since they are created only once and live as long as the webapp.
It will be interesting to see how you guys come along with this in PHP.
Hi...
You would want a DI framework for testing. You want to inject Stubs during acceptance tests and stubs/mocks during more complex unit tests. Paul Hamant is very much an XP'er and part of the original motivation was for testing components outside of a servelet (avoiding Cactus I believe, but I cannot rememeber the original conversation).
Build it...please!
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Yes, good point. I haven't thought about it!
OK, I'll speak to guys from Pico team and ask if I could host PHP version there. (Just don't have own web site at the moment).
Could You provide me with real example (test case with mocks I guess), so I have REAL code to test Pico port with?
Best regards,
Pawel Kozlowski
Hi...
The person to ask is Jason, as he has a homebrew DI system of his own. I tend to refactor the code so that I don't need one and pass a factory or two from the top level script. Maybe the odd Registry on occasion.
One example I can think of is changing the DB for higher level integration/acceptance testing. In this case the DB connection (or it's factory) is not nearly as accessable, as you want to set it up in a test script without touching the code. Something like...
If you want a non-Java DI framework example, have a look at the Ruby "Needle". I haven't looked at it, but it seems to be influenced by Spring.PHP Code:class BigTest extends UnitTestCase {
function setUp() {
$connection = &new MysqlConnection('localhost', 'test', 'test', 'test');
$this->inject('Connection', $connection); // Uses DI.
$this->clearDatabase();
}
function tearDown() {
$this->clearDatabase();
}
function inject($class, &$object) {
...
}
function clearDatabase() {
...
}
function testSomethingWithDatabase() {
...
}
}
yours, Marcus
p.s. I may be able to help with the project later as a user, as I can see uses for this in the Arbiter project.
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Have you thought about a sourceforge.net account, or berlios.de where you have a choice of CVS/SVN?
I've been using berlios myself for several months now and would recommend them.
Hi,
Finally, I’ve cleared up the code for Pico port. Now, I’m able to do sth like this.:
All the magic happens inside Pico!PHP Code:class DBConnection
{
private $db_user;
private $db_pass;
public function __construct($db_user, $db_pass)
{
$this->db_user = $db_user;
$this->db_pass = $db_pass;
}
public function getUser()
{
return $this->db_user;
}
public function getPass()
{
return $this->db_pass;
}
}
class TestDBDao
{
private $db_conn;
public function __construct(DBConnection $db_conn)
{
$this->db_conn = $db_conn;
}
public function getDBConnection()
{
return $this->db_conn;
}
}
function testSample()
{
$pico = new DefaultPicoContainer(new CachingComponentAdapterFactory(new ConstructorInjectionComponentAdapterFactory()));
$pico->registerComponentImplementation('DBConnection','DBConnection','',array(new ConstantParameter('user'), new ConstantParameter('pass')));
$pico->registerComponentImplementation('TestDBDao');
$conn = $pico->getComponentInstance('TestDBDao')->getDBConnection();
$this->assertIsA($conn,'DBConnection');
$this->assertEqual($conn->getUser(),'user');
$this->assertEqual($conn->getPass(),'pass');
}
I’ll let You know as soon as project is available somewhere (like codehouse of sourceforge). If You want get your hands dirty with this project – let me know. Also, if you have use cases for DI, please, let me know asap.
Best regards,
Pawel Kozlowski
Hi,
Thanks for the hint. I’ll try with codehouse first, as I believe it would be ‘good thing’ to have all the pico ports in one place (You know, it’s easy to reach, with docs and do on).
If it’s not going to work I’ll go with berlios.
Cheers,
pawelik
How can I reach him?
Should it be something like...
I'm not sure if it’s what You are thinking about...PHP Code:class BigTest extends UnitTestCase {
function setUp() {
$pico = new DefaultPicoContainer();
$pico->registerComponentImplementation(
'DBConnection', //component key
'DBConnection', //component class
'', //component class includ file
array( //component params, like host, login and pass
....
new ConstantParameter('user'),
new ConstantParameter('pass'),));
$this->pico = $pico;
}
function tearDown() {
$this->clearDatabase();
}
function testSomethingWithDatabase() {
$componentToTest = $this->pico->getComponentInstance('sth using the DB');
}
}
Would be great! I’ll let You guys know from where to download the package.
Cheers,
pawelik
He is lurking on the thread
and will certainly want to poke around at it.
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
Hi, I've just (about 5 minutes ago...) PHP5 version of Pico. You can grab it from codehaus CVS repository (http://www.picocontainer.org/Source+Repositories).
There is still a lot to do, but finaly it's in the repository.
Uuu, sound like a lot of work. I have to warn You that commited code is rather proof - of -concept then productio-quality code. I would start with sth less complicated. I'm still not sure should DI every aspect of web framework in PHP.
I'l try to post sth longer about this tommorow.
Cheers,
pawelik
Wohoo !
Not that much, I just wanted to remove the Context class and have Request, User, ... passed trough the contructor. I think not every object should have access to the whole context. It must be depending of it's "role".
For example the View class doesn't need a DatabaseManager. I still have to elaborate the whole.
Thanks for the code, you'll probably get some feedback by the time you post a longer answere
Cheers,
... zimba
Guys, please, have look at http://www.sitepoint.com/forums/showthread.php?t=232030
Thanks for the code, you'll probably get some feedback by the time you post a longer answere
I've started new thread.
Cheers,
pawelik
Posting Permissions
Bookmarks