The Future of Zend Framework is Solar

By | November 11, 2009

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:

http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

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.

goto

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.

Modesty

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.

Conclusion

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

35 thoughts on “The Future of Zend Framework is Solar

  1. pcdinh

    I find that the way Zend Framework (or Symfony) take to move PHP community forward is just wrong. Zend Framework is over-engineered, uses too heavy object oriented model. Developers behind Zend Framework try their all best to satisfy Java developers. But PHP is all about a simple, light weight approach to web development. Making PHP less fun, more complicated is just wrong by any mean. They just forgot how PHP dominates the world.

    SolarPHP, CakePHP 3, Kohana 3 are good PHP frameworks. But I think that Solar is smarter and more innovative.

    Thanks

    Dinh

    Reply
  2. David

    bu bu but but but….Solar doesn’t have a stable release yet.

    Yes, I’m aware that Solar is “stable enough” but “Alpha” tends to scare people away. Label it “Beta” and people will come in droves. Afterall, on the web “Beta” means Google awesomeness. ;-)

    Reply
  3. T

    In one really important area Solar is far behind to ZF and that is community. My opinion is that community matters more than any technical details.

    Reply
  4. ivo jansch

    it’s almost like saying that the future of home depot is starbucks if tomorrow they start selling coffee and muffins. Or the future of mercedes is bmw because both of them have all the features you’d expect from a car. A framework is defined by more than its features, making posts like this indeed just a cheerleading attempt. In my humble opinion, and so on…

    Reply
  5. Maarten Stolte

    It’s cool your framework has a lot of stuff ZF is going to implement, it means you’re probably going in a sane direction if others are doing the same.
    Still, when people consider a framework they consider more then just the features, they also consider things like ease of use, quality (unittesting+documentation), and most importantly for a lot of companies, how easy it is to find new developers that know the framework.
    With Solar compared to ZF I’d say that last one will be very hard for you guys, but I wish you best of luck, competition is important.

    Reply
  6. Hodicska Gergely

    First thing: I am not using any of the mentioned framework while at Ustream I created a highly optimized framework, but I am mainly familiar with both framework as I checked more times their source code. I always liked Solar, but I think this post is a little pointless: the mentioned features are not too unique, they are part of a natural evolution. I think even symfony could say that it is the future of ZF (or other frameworks which are already on a higher level). But why are you even developing a PHP framework while Rails has already this features? And the other things is that you did not mention that features that ZF has and Solar not.

    Reply
  7. ace

    Isnt a bad practice if all classes inherit from same parent? Protected becomes public this way.

    Reply
  8. Marco

    You can have namespace-like support right now with Zend Framework too.

    “why wait for ZF 2.0 when you can have all those features and more, right now, by using Solar?”
    because, right now, in ZF you have some other features which you don’t have in Solar??

    Seriously, I’m not using neither Solar, neither ZF, but this post is kinda “low”, would be better to invest the time spent on it into writing some narrative docs ;)

    Reply
  9. Bojan Zivanovic

    Why wait for ZF 2.0 when you can have all those features and more, right now, by using Solar?
    ————————————————-
    Because of large amounts of code already written, using ZF 1.x
    I am not happy with the current state of ZF, but the codebases that I’m maintaining (two large projects) are too large to switch to another framework, so I’m waiting for ZF 2.0 (and ensuring everything works with PHP 5.3 in the meantime)

    Reply
  10. Fred Wu

    As impressive as Solar is, Zend Framework still has far more readily available libraries such as Zend_Search_Lucene and Zend_Service_Twitter which aren’t available in Solar.

    I agree with pcdinh, Zend Framework is too Java-like and is over engineered. What ever happened to its original marketing pitch – “extreme simplicity”?

    Reply
  11. Giorgio Sironi

    Wait, Zend Framework has no Model component and will never have, and Solar neither have it. What can be included is a Data Mapper that addresses the need for persisting objects in a relational database. What Zend Framework is going to support is Doctrine 2, a real Orm that let the developer use POPO for entities instead of subclassing. It will be a shared standard with Symfony (a la Hibernate).

    Reply
  12. Ren

    I’m far from convinced that unified constructors are a good idea, especially with 5.3.

    The fact that framework code has to interface databases/memcache/etc means it is not that unified.

    Reply
  13. Pádraic Brady

    Overengineering is a soft target. Remember that the ZF deliberately avoids a degree of simple coupling (aka Full-Stack) in favour of a looser component architecture. The result has been an evolution of a) duplication and b) integration. The two combined feel overengineered but on a component basis the overengineering is not so visible. It’s never more obvious than in the MVC area – something the roadmap already notes as needing improvement. As with all software, the ZF has been moving forward. Zend_Application was a huge step, and there are doubtless others waiting in the wings that will hit ZF 2.0.

    Actually, I think Paul’s post is quite right to point out Solar’s advantages. There is far too little prodding, questioning and criticism around frameworks in my opinion. Many developers forget that the ZF is not a “new” framework. In software years, it’s positively ancient! Of course there will be a long list of improvements badly needed, and Paul’s post does nothing more than point out a few of them that (on a positive note) the ZF 2.0 roadmap identifies at an early stage.

    I will take issue with the Model mention though ;). Creating a generic Model layer (not a project specific layer) is insanely difficult and requires a massive amount of man hours. The Zend variant was dropped for some very good reasons. Benjamin was working on it alone (no help). It’s a massive undertaking. Database expertise (i.e. all RDBMSs) is rare in the ZF developer group. Maintenance was going to be an unforgiving bitch. And Doctrine 2 was simply well ahead, in existence, has amazing support and adoption, and just fits really well into the equation. There is nothing wrong whatsoever with recognising a weakness and resolving it with a third party external.

    So with that one aside – can we lay off Paul? His points are valid. If a developer thinks they are upsetting, then sign up as a ZF 2.0 developer so you can chant nanananana at Paul in a few months ;).

    Reply
  14. Pingback: Paul Jones’ Blog: The Future of Zend Framework is Solar | Webs Developer

  15. Richard Harrison

    I don’t think being bitter is going to get more people using Solar.

    Perhaps ignoring your tutorials / making it less accessible is a big reason for low adoption; or perhaps it’s some other reason that is within your control. Perhaps being so “similar” to ZF could be a problem. What is your USP?

    A common problem with startup-businesses is creating a solution to a problem that doesn’t exist. They spend time and money creating a functional product and then don’t understand why no one wants to buy it. Perhaps this is something similar.

    Reply
  16. Richard Thomas

    For those that feel changing frameworks is to large of a task understand that the change from ZF 1.X to 2.X is going to be a major undertaking.

    ZF group has clearly stated that they will not just be moving to php 5.3 with 2.X but that they will be breaking BC along the way. They even stated at ZendCon that the break is going to be wide enough that they are trying to program “helpers scripts” to assist in the migration.

    Reply
  17. Les

    A lot of people think the Zend Framework is really good, but it’s not – things mentioned for 2.0 are things that should have been dealt with prior to even version 1.0, but like yourself, I saw that one coming.

    Zend Framework is bloated, bulked out by a) features most developers don’t even use, nor care for and b) badly designed class structures that not only bend best practice rules, but break them – with a team of developers working on a project, you do need standards and there are none.

    You have one contributor doing it their way, and along comes another contributor who does it his way, and what do you get?

    Exactly. I suggest for 2.0 the team completely strips out the bloat, and forks a “Lite” version, bare bones for those developers who are really only looking for the very basics, such as the Front Controller and the Model, View and Controller and nowt else.

    Doubt they’ll listen as they have failed to listen so far, so let the bloat continue is my impression. There is going to come a time, this framework [Zend Framework] will make a lot of people puke up all over the place.

    Reply
  18. pimpinken

    You should invest some time writing good documentation, articles, etc. about Solar. I think you’ll find it much more successful instead of doing stupid things like this. Maybe people don’t know about and use Solar because the documentation is not informative enough so they don’t know all this stuff exists.

    Reply
  19. Meketrefe

    Hi Paul,

    With due respect, the problem with your rant about ZF and your subsequent cheerleading post is that of some more than 1100, 33% claim to be using ZF and nobody (maybe those 15% claiming to use “Other”) seems to be admitedly using Solar: http://twtpoll.com/mayflowerphp

    This should make you reflect a bit: Either Solar is not that superdupper, it is not properly “marketed” or it’s not that good compared to other frameworks…

    Just for the sake of real modesty… ;-)

    Reply
  20. Pingback: Why I am not running to Solar « LAMPlights

  21. Jon E

    I thought this was a great post! This didn’t feel like a post about “mine is better than yours”. I don’t think that’s the point. Articles like this are great at showing some of the similarities and differences between good projects and how two high-quality frameworks are (or will be) approaching problems in similar ways. I use Solar daily; I think it’s the cat’s pajamas, but I would never say that the ZF is sub-par because that would be crazy talk. There are too many top-notch developers working on it to be anything less than a top quality framework. Solar doesn’t have a big following or teams of developers and sponsorship, but it is still a great tool. It would be great to see some other people give it a shot. Take a couple of hours to dive in and play around. If you need help, ask! Those who use it would be more than happy to lend a hand. If you can’t get into it, fair enough. But if you do, please tell others and contribute in any way you can.

    The Solar manual and tutorials do need work. Just be patient. With a little more time, these resources will improve immensely.

    Good post, Paul.

    Reply
  22. Pingback: elofson.ca » Blog Archive » Start Using a Top Quality Framework “Right Now” - Jon’s blog about web development and other stuff

  23. Robert P

    “not writing about the framework. You can help with that if you like”

    I probably would contribute, but I can’t justify the time it would take to learn Solar due to its lack of documentation.

    But still, kudos on what appears to be a very mature framework. And on route rewriting making it to the beta release.

    Reply
  24. dreese

    I have looked at Solar on and off since its genesis. I started using the Savant template system years ago — I think it was a 1.x release — and have built some major commercial sites using it (and a custom MVSish framework). I finally started a new project earlier this year that allowed me to choose a new framework. I wanted to go with Solar, but b/c breaking changes were still being made and I banged my head against the no documentation situation for longer than my schedule allowed.

    I started using Zend and found it pretty easy to get going. The documentation and community that has been mentioned in these comments provided what I needed at the time. That said, I would definitely consider Solar for a future project, as I don’t need the Lucene, Twitter, etc. support that some use as examples of Zend being more complete. I would actually prefer to scale back to a more lightweight framework at this point.

    What would help me is a migration guide — something that illustrates “in Zend you to , but in Solar you do .” This might sound petty, but I have been doing this long enough that I dread learning yet another way to do essentially the same thing. All my web apps interact with a database, populate template variables, collect form data, parse xml, make http requests, etc.

    Some people relish the idea of learning a new language/framework/paradigm. Maybe I’m getting old, but I just want to get to the finished product these days.

    Reply
  25. Pingback: Zend Framework Blog » Blog Archive » Aus den Zend Framework Blogs

  26. Rob Riggen

    Touche, Mr Paul Jones! Great cheer leading and great work on your framework. Sorry I’m late to the lunch line on this one but glad I read it.

    Reply
  27. zelnaga

    It’s ironic that proponents of this framework would dismiss Zend as being over-engineered when this blogs own caption is “If it’s worth doing, it’s worth over-doing”.

    Reply
  28. Joe Devon

    I wanted to say what Padraic did about Doctrine…

    If you AREN’T planning to use Doctrine or similar project, I think you will regret it. Getting the required expertise to do well what Doctrine does is harder probably than building the entire rest of your framework.

    Reply
  29. Pingback: Solar 1.0 lanzado | Matias Aracena

  30. Christof Coetzee

    I’ve been developing with Zend Framework for quite some time now, and must say that that MVC in general is the way forward.
    There are many other PHP MVC frameworks thats been available long before Zend Framework – CakePHP, Code Igniter etc.

    But one thing you must understand is that the Zend Framework has the Zend company as well as IBM behind it, which is a huge advantage in terms of support, future availability, and quality code.

    Magento (one of the leading ecommerce platforms) also uses Zend Framework as part of the stack, Magento’s decision to use ZF as appose to other frameworks was a clear-cut one.

    Reply
  31. Pieter

    One thing I’m always wondering about… What’s up with all the underscores!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *