Paul M. Jones

(This is an edited and collated version of an email thread from the solar-talk list.)

Even though (or perhaps because) the Solar project pre-dates the newly-released Zend Framework by about a year, I've had a couple of private emails asking me if I will discontinue Solar, or rewrite Solar on top of the Zend Framework. The short answer to both of these, at least for now, is "No -- Solar is not going away." Especially now that I'm not at Zend any more. ;-)

The long answer is, "Even though Solar and Zend Framework share a similar underlying architecture, Solar has implementation goals that are quite different than Zend Framework; these differences make it reasonable to continue Solar as a separate project."

Here are some of the main similarities between the two projects:

• An overarching "main" class of static methods to provide common functionality for the remaining library classes, with things like a registry, a class loader, a file-finder on the include path, etc.
• Significant adherence to PEAR standards for class naming convention and directory structure, where the class "Example_Class_Name" maps to "Example/Class/Name.php".
• Classes for common web application needs: input validation and filtering; database API abstraction and query generation; URI manipulation; model, view, and controller classes; and so on. Some of these even have similar names, owing to their common adherence to Design Patterns.
• They're both still under development. ;-)

But there are some significant technical differences between the two projects. Here are some examples just from the overarching "main" Solar class:

• Solar uses a unified constructor mechanism. All Solar classes are constructed in exactly the same way, using an array of config options as the only constructor parameter. This makes is possible to provide ...
• A unified configuration mechanism. Basically, you have a single config file that returns a PHP array keyed on class names. Classes can look up their own configuration automatically when constructed, because the __construct() signature is always the same. This also means that Solar can have ...
• A universal factory method. A call to Solar::factory('Class_Name'), optionally with a factory-time config to override the defaults, will get you a new instance of any Solar-compatible class. This factory mechanism is used for the Solar::registry() (originally called Solar::shared()), and is also used for ...
• A unified dependency-injector method. In short, you can call Solar::dependency() and it will retrieve a dependency object for you, either from the registry, from a passed object, or by constructing a new object for you on-the-fly. All you need to do is provide the class name and a specification for the dependency.

Solar currently provides other features not yet present in the Zend Framework:

• built-in localization
• read-once flashes
• automated exception generation with localized messages
• form processing
• fully-automated form output generation (whole forms with layout, not just form elements)
• user authentication and role classes

And of course, Solar is licensed under the LGPL (which is FSF/OSI approved).

So what does Zend Framework have that Solar does not?

• A whole lot of specialty classes. The Zend Feed, Service, and XMLRPC libraries are fantastic, as well as the PDF generator and the Lucene-based search engine in the incubator. These are all excellent work. Solar has nothing to compare with these; I would call them the real gems of the Zend Framework.
• About a dozen regular individual and corporate developers, and the backing of a real business, to support and drive its development. Solar only has one guy (yours truly) doing regular development, and the good will of a few regular contributors and users (Clay, Matthew, Jean-Eric, Jeff, Stuardo, and others).
• A great marketing apparatus. Solar, by contrast, has only word-of-mouth and a few blog entries.
• More automated tests, and more-and-better documentation. These things I really need to work on for Solar; in fact, documentation has been almost the only thing I've been working on for the past few days (more on that in a later post).

Mike Naberezny brings up a great point about the original question of whether or not Solar is going to continue in relation to Zend Framework:

I think that the underlying premise of these questions is very wrong. It is not necessary to choose one over the other -- you are always free to mix and match them at will. That's always been the PHP way.

I can only agree -- it was like when I got emails asking "how is Solar different from PEAR?". The three (PEAR, Solar, Zend Framework) are not really that different architecturally; Solar owes quite a lot to the PEAR standards for class naming, directory hierarchy, coding standards, and so on. Each of the projects has its own dependencies and idiosyncrasies, but if you know how each project works, then you can work on combining pieces from them effectively. The key differences are in the implementations, the little tweaks each makes to the related design patterns, and the society/culture/support-group that grows up around them. (That last part about culture is too often neglected; I like to think the Solar social norms are more approachable for anyone with a learning/mentoring attitude toward programming.)

Having said that, a programmer or team is probably going to pick a core body of code to work from (even if it's internal-only) and then add to it from other sources. I got the idea the questions were asked in this sense; i.e., "Is Solar going away as a core foundation to start from?" not "Should we use it exclusively?" Of course it would make no sense to use Solar or PEAR or Zend Framework exclusively, but each serves as a pretty good base to work from in their own ways.

Limiting yourself to one source of libraries means giving up one of the primary advantages for using PHP and only limits what you can do.

Totally agreed here; there's no reason not to mix pieces from different code bases, especially regarding ZF and Solar (since their architectures are so similar, and since each has things the other does not).