The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.

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.

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.

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.

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

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).

Could You provide me with real example (test case with mocks I guess), so I have REAL code to test Pico port with?

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...

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.

The person to ask is Jason, as he has a homebrew DI system of his own.

How can I reach him?

Originally Posted by lastcraft

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.

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, do you have any news about your implementation ?

I'm still interested in it. I'd like to port Mojavi to DI just for the test.

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.

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.

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