Dependency Injection in Solar

Jeff Moore talks about dependency injection in PHP and opines as to how he’d like to see “the current crop of frameworks” adopt the technique. Jeff, your wish is granted! (At least for Solar. 😉

Because it makes great use of dependecy injection, Solar has a standardized form of generating/retrieving dependency objects using its Solar::dependency() method.

The calling code sends the dependency params to the target object at construction time. The target object then passes those params through Solar::dependency() to retrieve or create the dependency object.

The params may be an object (the dependency object itself), or a string (treated as a registry key for Solar_Registry::get()), or an array (which are treated as params to create a new dependency object internally at the target using Solar::factory()).

UPDATE (2009-03-28): Updating documentation links.

Solar 0.20.0 released

Exactly one month after the last release, I have uploaded version 0.20.0 alpha. There are lots of changes in this release, but the biggest news is that the page-controller now uses method-based actions (as opposed to file-based actions).

You can read the change notes here, but it’s a really long list. If you want something a little more readable, with better narrative, you’ll find it after the jump below. The new page-controller information is especially good. However, the narrative is quite long, so consider yourself warned. 😉

Continue reading

No More Loners!

Read and heed the latest from Clay Loveless: Stop Writing Loner Applications.

After nearly a decade in web application development, I continue to be dumbfounded by how many applications are built and released by the open-source community that apparently believe that they’ll be the only complex, user-database application I’ll will want to run.

In nearly every case, these loners have been built with no apparent concern for the fact that the person or company involved may already have a database of users, or that one of the other applications may be installed alongside it. Hard to believe, but true.

The result is that the guys in the trenches trying to put together a cohesive whole have to spend a great deal of their cycles writing and maintaining “bridge code” to allow site visitors to register and authenticate against all of the chosen applications at once. …

Right on, Clay. Authentication and user-profile support in particular are a real burden to bear. I’ve tried very hard to make my apps (such as YaWiki) authentication-system agnostic, and the user-info related classes in Solar are read-only for exactly that reason.

One of the nice things about Solar-based authentication is that it is adapter based: you can change the backend from an LDAP server to an email server, or to a .htaccess file, and you never need to change your application code. (PEAR Auth also provides decent tools for this if you need PHP4 support.)

I have one other major criticism of most public code: classes are not generally namespaced properly. It’s as if project managers think theirs is the only “User” or “Member” class in the world. All classes need, at a minimum, a project-name or vendor-name prefix. (Consistency in naming is a related issue, but I’ll save that for another time.)

This is one thing the Zend Framework gets right, although it was against their will for a very long time. (All Zend classes are prefixed with “Zend_” so they automatically deconflict with all other userland classes.) That’s one thing I’m glad I kept yammering about while I was at Zend; it took months to get the managers to accept that as a naming convention, and even then it was only through the combined efforts of numerous developers to push it through.