The Future of Zend Framework is Solar

I have said it before and I’ll say it again now: If you want to see the future of Zend Framework, look at the Solar Framework for PHP 5.

FYI: This is a cheerleading post. Some will be annoyed by it or find it “unfair”. Others may find it informative and enlightening. I make no apology for advocating what I think are the good things about Solar, especially when other projects appear to be mimicking those things.

I noticed that Matthew posted the ZF 2.0 roadmap yesterday:

Solar is already doing most of what is described as the future for Zend. Let’s go over this, shall we?

Unified constructor. All constructors will (optionally) accept an array of options or Zend_Config object as the first argument. This allows for more flexibility to add new arguments to the constructor, have variable numbers of arguments, and allow “named” arguments. Additionally, it’s a good technique for allowing Dependency Injection.

Solar has had a framework-wide unified constructor for years now. As far as I know, Solar is the first PHP framework to demonstrate this design pattern and give it a name. You can have a unified constructor right now with Solar.

In addition, we already have a unified dependency injection and service locator implementation, via the unified configuration mechanism and a lazy-loading registry. You can have DI/SL right now with Solar.

Options. In ZF 1.X, the various components which accept options accept a variety of formats: some expect underscore_separated keys, others expect camelCasedKeys, others expect UPPERCASEDKEYS, and some expect lowercasedkeys. This leads to confusion for many, and also leads to difficulties debugging. Our goal in ZF 2.0 is to standardize option keys to correct this situation.

Currently, we are leaning towards all_lowercase_underscore_keys.

Solar has already standardized on its config keys as lowercase-underscore. You can have standard config keys right now with Solar.

Exceptions. Each component will have an Exception marker interface, with exceptions defined for discrete exception types thrown by the component. The concrete exceptions will either extend the global Exception class or an SPL Exception, and also implement the component Exception interface.

Solar provides a unified exception mechanism already. This is not quite the same thing as described in the ZF2.0 document, but if the idea is to have a unified way of throwing and recognizing exceptions, Solar is already doing it.

Design By Contract.

OK, we don’t really do this. Solar tends to use adapters, plugins, class stacks, and duck typing, not interfaces.

Elimination of most singletons.

Solar doesn’t use singletons. We use the registry and, occasionally, unified static-method-collection classes. You want two or more database connections? Mark them for lazy-load in the registry, and set your config file to use the appropriate service locator keys for whatever objects may need them. You can have this right now with Solar.

Creation of components for general-purpose, cross-functional actions. A number of components duplicate code, and we want to push the duplication areas into discrete components that the original components may then consume. Some of these include:

  • Plugins/Helpers/Strategies (seen currently in Zend_Controller_Front, Zend_Controller_Action_Helper, Zend_View (helpers and filters), Zend_Form (validators, filters, and decorators), etc.). Plugin discovery and loading could benefit from a common API.
  • Decorators (seen currently in Zend_Form; other areas could benefit from the pattern)
  • Factories (seen currently in Zend_Db, Zend_Navigation_Page, Zend_Auth, Zend_Translate, Zend_Cache, etc.)
  • Caching (seen currently in Zend_Translate, Zend_Locale, Zend_Queue, Zend_Paginator, Zend_Feed_Reader, Zend_Db_Table, etc.)

Solar already has a standardized factory mechanism and a standardized adapter approach. With the lazy-loading registry and DI/SL mechanism we can inject a cache object into any other object that’s ready to receive it. You can have these right now with Solar.

(In fairness, we don’t use decorators much, and the plugin systems are more a standard approach using class stacks than an encapsulated system.)

Usage of new language features within plugin architectures.

Solar isn’t on 5.3 yet, but then, neither is Zend Framework.

Autoload-only. We will move to using autoloading throughout the framework. This solves a number of performance issues, as well as simplifies coding dependencies (particularly exceptions).

Solar is already autoload-only. You can be autoload-only too right now with Solar.

Namespaces. PHP namespaces benefit frameworks and libraries more than any other code bases, and ZF can benefit from it greatly, particularly with components such as Zend_Search_Lucene and Zend_Controller.

Solar already has first-class support for PHP 4/5 style namespaces (i.e., pseudo-namespaces) and supports mixing of multiple “vendor” prefixes in projects (and supports cross-vendor fallbacks across library hierarchies). Solar expects that you will be working within your own pseudo-namespace already, and so is poised to use 5.3 namespaces proper with little effort. You can have namespace-like support right now with Solar.


As with “new language features” above, Solar isn’t on 5.3 yet, but then, neither is Zend Framework.

MVC Implementation: Our current MVC implementation is increasingly adding overhead to the dispatch cycle, slowing down the request cycle. While you can squeeze additional performance out of it via stripping require_once calls and using autoloading, the fastest requests are still far short of other, slimmer frameworks …

Solar‘s dynamic dispatch cycle is much faster than the one in Zend Framework, and has been for years; see these benchmarking posts:

You can have a much faster dispatch cycle right now by using Solar.

Models and Master-Slave

One more thing that Zend Framework doesn’t have, that Solar does, is an integrated model system. Zend Framework recently dropped the idea of having their own, and expect to depend on an external system for reasonable model/record/collection support. Solar has an integrated model system right now with support for single table inheritance, various relationships, unified saving of object graphs, automatic data filtering, automatic form generation, calculated columns, collection methods, automatic data caching and clearing, and much more.

Yet another thing: we also provide support out-of-the-box for master-slave MySQL replication, with no changes needed to the codebase. Change your config file from the single-server connection to the master-slave connection, and you are done. (Well, you might have to wrap some parts in transactions, but after that, it will work on both single-server and master-slave setups.)

You can have robust models and master-slave support right now with Solar.


There is one significant thing that Zend has that Solar doesn’t: narrative documentation. Our API docs are second to none, but the tutorials are lacking. We’ve been spending our time making the framework great, not writing about the framework. You can help with that if you like by adding to the wiki.


The point of all this is not to belittle Zend, Zend Framework, its developers, or its contributors. The point is to ask Zend Framework adopters: why wait for ZF 2.0 when you can have all those features and more, right now, by using Solar?

(Let the ZF apologists begin their comments right now. 😉

When only the glib win, we all lose

Memorize this: “I have some concerns, but I need a little time before I can really articulate them.”

If you're a manager, or anyone who leads meetings and discussions, please PLEASE have respect for that phrase. It's unlikely (but possible, sure) that someone will abuse this, since “buying time” in the context of a work decision doesn't usually buy us anything other than the chance to think more deeply.

via Creating Passionate Users: When only the glib win, we all lose.

Agile Gone Bad?

Agile ain’t agile no more when adopted as the official enterprise software development process. The problem with agile is “agile != flexible”.

Agile was born in the world of contractors who have to show something for the money at every status meeting. For a while clients let themselves fooled with use cases written on many hundreds of pages but this doesn’t work no more. They smartened up and demanded to see something working, for a change. Agile came in handy because it allows to show a prototype early on. As long as you keep adding features to it and you are able to demo them there is a good chance your contract will be extended.

While in theory the Agile methodologies tell you to be flexible, the cruel reality is that most people that apply them don’t think a lot before taking the manual and enforcing every bullet point with a thick stick.

via Software development dogmata – good practices gone bad | Little Tutorials.

Solar 1.0.0alpha5 Released

Solar 1.0.0alpha5 has been released, with a few bugfixes and one change. The change notes are below. Also of note, I have created separate "alpha" and "beta" branches, so we can continue bugfix releases on the alpha side while not having to release new beta features.

  • Solar_Form
    • [FIX] Form attributes for id, name, and class are now reset properly. Thanks, jelofson and stloyd, for the report and patch.
  • Solar_Class
    • [FIX] Do not use $this for exceptions in a static method call. Thanks, Richard Thomas, for the report and patch.
  • Solar_Sql_Model_Cache
    • [FIX] Method getCacheKey() now converts the fetch params to array before unsetting values. Was previously unsetting the ‘cache’ value (among others) causing cache results not to be saved in Solar_Sql_Model. Thanks, Anthony Gentile, for the report that led to this fix.
    • [FIX] Default adapter is now Solar_Cache_Adapter_None, as it is in Solar_Sql_Model.
  • Solar_Sql_Model_Params_Eager
    • [CHG] Method joinCond() (and array key ‘join_cond’) now accept arrays for cond => val the same way where() and having() do in fetch params. Thanks, Anthony Gentile, for the report that led to this change.
  • Solar_Sql_Model_Params_Fetch
    • [FIX] In method cache(), use $this, not $$this. Was preventing the cache value from being set, so it was always null. Thanks, Anthony Gentile, for the report that led to this fix.
  • Solar_Sql_Model_Record
    • [FIX] In method newFilter(), do not add filters for table cols that are not part of the fetch cols. All other filters are still added.
  • Solar_Sql_Model_Related_HasManyThrough
    • [FIX] In _modEagerFetchJoin(), cast the base join conditions to array before merging.

Forty Percent!

Big news (for me anyway): my employer, OmniTI, is allowing me to spend a minimum of 40% of my paid work time on the Solar Framework for PHP 5 (plus additional time as duty allows). The project remains open-source under New BSD license.

The agreement has been in place for several weeks now, and has allowed me to put a lot more effort into the project lately (as a review the SVN logs will reveal) while keeping a paycheck. At the same time, OmniTI gets to show its support for one of the many the open-source communities it has been able to build its business on. Thanks, Theo and Ciprian, for this generous allowance. I appreciate it, and so does everyone who uses Solar; I think it’s a big win-win all around.

Scalable Internet Architecture

This is not strictly PHP, but it is about scalability, and every PHP programmer *ought* to be thinking about this stuff.

Theo Schlossnagle of OmniTI (where I work as a web architect) has this slide deck posted about Scalable Internet Architecture:


(Aside: I joke that at OmniTI, my reporting chain looks like this: from God, to Theo, to my director, to me, to my subordinates.)

Developers (PHP and otherwise) should read the whole thing.

Some highlights, with comment and paraphrasing from me:

  • Slide 7: “Lack of awareness of the other disciplines is bad.” Developers need to be aware of the advantages and constraints presented by everyone else: designers, DBAs, sys admins, network engineers, etc. Not being aware means making your own work more difficult (bad) or their work more difficult (also bad, especially in teams).
  • Slide 14: Craftsmanship and discipline: learn it, love it, live it. It’s very difficult to be consistently attentive; don’t let the fact that you cannot *always* be attentive stop you from *always trying* to be attentive.
  • Slide 29: Know the difference between “premature optimization” and “necessary optimization”. This is hard.
  • Slide 48: The networking architecture is critical to scaling. Everybody forgets about the network because it’s “just there” (until it’s not).
  • Slide 59: “Scaling is hard, performance is easier. Extremely high-performance systems tend to be easier to scale, because they don’t have to SCALE as much.”
  • Slide 63: Combine this with slide 59, and you have the reason why you need to know your application responsiveness (i.e., benchmarks). As part of this you need to know the overhead imposed by your framework of choice, so that you know exactly how far you can optimize your application. This will help you decide where to spend your limited resources: on development to improve application performance, on hardware to improve system performance, or on adding systems for horizontal scaling.