Aura for PHP 5.3+, aka Solar 2.0

By | March 2, 2011

Measuring from the first Subversion commit, Solar was 6 years old on 14 Feb 2011. The project has come a long way since then, and has evolved from a collection of library classes with some content domain models, to a general purpose framework.

Moore’s Law tells us computer power doubles about every 18 months; it’s how we measure generations for computers. 6 years is 4 generations, which makes Solar the equivalent of an 80 to 100 year old person. Just like with a mature person, there is a great deal of knowledge and craft embedded in Solar, but it also still shows its roots and carries the weight of decisions from early in its life.

With all that in mind, it’s time to start working on Solar version two, using the formal namespaces and other features of PHP 5.3. There are some other very significant changes on the way as well.

The first change is the name of the project. Even though Solar (the PHP 5 framework) came first, the name is too easy to confuse with Apache Solr (the search system). So, after some discussion with others, Solar v2 will be called Aura.

The second change is in the fundamental organization of the project. Solar became a full-stack framework very quickly, with all classes descending from a base class, and using and a service locator to manage dependencies. By comparison, Aura is a collection of independent library packages; it uses no base classes, and is oriented toward a dependency injection container proper to manage dependencies. Aura also has an additional “system” package that assembles those libraries into a cohesive framework (the way Solar is now). That way, those who want to use only one or two Aura packages can do so, and developers who want a full framework can also get what they need.

There are lots of other significant changes, and I expect I’ll write about those in the future. Until then, if the project sounds interesting, you can find the Github repos at https://github.com/auraphp. Aura also has a mailing list at https://groups.google.com/group/auraphp, and you can join the IRC room on Freenode at #auraphp.

Meanwhile, Solar will keep getting as much love and attention as it has over the past year or so. But I do expect, eventually, that we will be able to extract all the best Solar behaviors to Aura. Solar won’t ever really go away (software projects almost never do), but I expect it will be eclipsed by Aura at some point in the future.

You can see what Aura looks like by examining the various Aura packages already in place:

  • Aura.Autoload, an autoloader package
  • Aura.Di, a dependency injection container,
  • Aura.Router, a web routing system,
  • Aura.Signal, a signal slots / event handler implementation,
  • Aura.Cli, a collection of command-line tools, and
  • the system package that provides a framework around the libraries

Take a look around; I hope PHP 5.3+ developers who want independent library packages will like what they see.

19 thoughts on “Aura for PHP 5.3+, aka Solar 2.0

  1. Court

    This is excellent news. I am not a Solar user, but I fully support any framework out there that is developed on 5.3+ and is built with proper decoupling in mind.

    Reply
  2. Rotimi

    Will the Solar_Sql_Model package be ported into the aura framework? It is my most prized part of the current Solar framework and I am eager for it to become an independent package that can be used in various contexts.

    Reply
  3. pmjones Post author

    @Rotimi: I’m glad to hear you like the Model system so much. I’m rather partial to it myself. :-)

    Yes, eventually Solar_Sql_Model will come over, but it’s not the highest-priority item at this point. The Solar_Sql_Model stuff is easily the largest single component of Solar, and will take quite a while to work through.

    Reply
  4. mario

    Too bad. I really liked the Solar base classes. But the new shitty namespace syntax will not creep into my projects. Why does nobody utilize the *useful* additions of PHP 5.3 ?

    Reply
  5. Tomek

    How usable are those classes in the current stage? Makes any sense to start carving some projects using them?

    Reply
    1. pmjones Post author

      @Tomek: I think the router, signal, and DI packages are useful right now, but they are not in production anywhere that I know of. The “cli” one is useful too, but requires some extra setup work. The “system” is a work-in-progress. Hope that helps.

      Reply
  6. till

    @mario: or maybe closures, lsb and __callStatic ;-))

    @Paul: congrats on the release, it seems you beat symfony2. ;) now come back to PEAR. thanks! :D

    Reply
  7. Lineke

    Paul, is there a roadmap somewhere for the aura project? When can we expect a version that is usable in a production environment?

    Reply
  8. pmjones Post author

    @Lineke: There’s no roadmap, exactly, but we do have a general information page. The page is ugly but informative: http://auraphp.github.com/

    At the end you will see a section titled “Conversion Priorities.” That’s the most of a roadmap we have right now.

    Reply
  9. Pingback: Paul Jones’ Blog: Aura for PHP 5.3+, aka Solar 2.0 | Steven's Blog

  10. Shane

    While puritanical design philosophy is nice (conceptually useful), it’s a bit disappointing here. I’ve always thought of Solar as mushed-together, but functional and efficient. Separation of concerns in programming is an idealogical comfort paid for in CPU cycles. (I guess this in the antithesis to @Court)

    Reply
  11. Hari K T

    What about updating the post ?
    The links are also broken as Aura changes the name from aura.package to Aura.Package .

    Reply
  12. Pingback: Programowanie w PHP » Blog Archive » Paul Jones’ Blog: Aura for PHP 5.3+, aka Solar 2.0

  13. ameros

    Is it really good idea to use “Interface” in the names of interfaces ? I find it actually a bit curious. I understand the “Abstract” as it may really be a part of a class name denoting that it is not precised as some work of art leaving the space for interpretation. Well abstract says: “designed for extension“. But interface? I would prefer it to have a name denoting the responsibility. So instead of “ContainerInterface” I would use “Container” (as it is already in DI we know that it is a DIContainer). And make some place (package, layer or just name) for implementation like SimpleContainer or DefaultContainer or ReflectiveContainer… And how can You say in interface documentation comment block: “Creates and returns a new instance of a class using reflection…” (ForgeInterface) ? This is the part of implementation but not of interface at all.

    Reply

Leave a Reply

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