Introduction

In a world of monolithic frameworks, the Aura project provides independent library packages for PHP 5.3+. These packages can be used alone, in concert with each other, or combined into a full-stack framework of their own.

The project is still young and just getting underway. Please fork the various library package repositories or the system skeleton repository, and help us keep high-quality libraries available and maintained for PHP 5.3+.

Join our mailing list at http://groups.google.com/group/auraphp, or chat with us using IRC on Freenode at #auraphp.

Getting started

Because the project is so young, there's not a lot in place yet. We do have a full system skeleton for developing libraries; check out the System project for more details.

If you like, you can use the various libraries on their own. The libraries available at this time are:

  • Autoload for a PSR-0 compliant autoloader
  • DI for dependency injection
  • Signal for signal slots / event handling
  • Cli for tools to build command-line controllers
  • Router for web routing independent of any particular framework

Background

The Aura project is essentially the second major version of Solar, reimagined and rewritten as a library collection with dependency injection instead of a framework with service location. The name change from Solar to Aura is to reduce confusion with the Apache Solr project.

Libraries first, framework second

The primary goal of Aura is to provide high-quality well-tested library packages that can be used in any codebase. This means developers can use as much or as little of the project as necessary.

Aura will have enough libraries to form a full-stack framework of its own. A system repository will be available to incorporate them all into a coherent framework for application development.

PHP 5.3+

Aura takes advantage of the features available in PHP 5.3+. This means formal namespaces, anonymous functions and closures, late static binding, and other features not available in PHP 5.2.x and earlier. In particular:

  • Use a top-level vendor name ("aura") and second-level package name ("di", "router", "web", "cli", etc);
  • Sub-namespaces are allowed, but they are not sub-packages, and are not distributed separately
  • Classes do not get sub-namespaces. E.g., "Exception" class cannot have an "Exception*" or "exception*" sub-namespace. Use sub-classes ("Exception_") or put the class in the sub-namespace so that they are all part of the same sub-namespace

Coding standards

The packages available through the Aura project all conform to the Horde/Pear/Solar/Zend coding standards. In particular:

  • No use of public properties, unless they are magic via get()/set()
  • No use of underscore with protected elements
  • Retain the Solar vocabulary

Self-containment

In line with the goal of "libraries first", all packages are as self-contained as possible and are independently downloadable. In some cases this level of independence may lead to some class duplication between packages. In other cases, it may lead to data-transfer objects being used to carry information across package boundaries, so that the package can be used with non-Aura codebases.

Sometimes complete self-containment is not possible. In these cases, the number of external packages dependencies is kept as small as possible. Packages with external dependencies have a DEPENDS file noting the other packages needed.

Techniques

  • Use dependency injection proper instead of the service-locator Solar::dependency() system; the basis for this exists at https://github.com/auraphp/aura.di
  • Find effective and reasonable uses for closures/anonymous functions, primarily for object creation within the dependency injector service definitions
  • More use of explicit mapping, as vs automatic searching of directory stacks.
  • Compose functionality as much as possible through dependency injection, instead of through inheritance and base classes
  • Use factories as object creators in general, rather than as adapter creators in specific
  • Windows Vista/7 support as-we-go, so that Windows users are part of the community from the very beginning

Conversion priorities

These are in relation to converting Solar packages and classes.

  • Concentrate on the dynamic dispatch cycle for web apps: bootstrap, front controller, page controller, and view.
  • Secondary or corollary concentration is on CLI and support classes.
  • Leave database and model work for much later (if ever).
  • Make it possible to have CLI controllers on a per-package basis.
  • Localization should be at the package level, not class-level.
  • Make it so that CLI and web controllers share a common vocabulary and execution pattern.
  • Use PHPUnit for testing in Aura. Write tests as we go. Aim for 100% coverage with each commit.