Paul Jones has a new post to his site showing how to merge one of the components of the Aura framework with the templating library Plates, a part of the The League of Extraordinary PHP Packages. In this post he shows how to integrate the Plates rendering engine into the Aura.Html component for use as a view layer.

Aura has its own native PHP template package, Aura.View, a direct descendant of Savant and Solar_View, as well as a cousin to Zend_View. The v1 Aura.View package used to include a helper system. Once we realized that there was no reason to tie the helper system directly to the view system, we released the helpers as a standalone Aura.Html package. This means the helpers can be used in any PHP presentation code, framework-based or otherwise.

Plates lets you register functions against its own internal handling, referencing the different elements to be rendered. He includes a code example showing this integration and how they look used in a Plates template.

Hari KT has a new post to his site today about a book he's been working around around the Aura framework that provides the missing manual for v2 of the project. He's publishing it as a book over on Leanpub too, so it's easy to grab...and for free too.

Aura has an awesome collection of libraries for different purpose. [...] If you are new to aura, there is probably something you may want to figure out yourself. Some of the components have version 1 and version 2 releases. There is a question of which branch corresponds to which version. [...] But people new to aura may be having hard time to find the specific documentation or may be stuck sometime. [...] I was talking with Paul M Jones regarding the documentation lately, and he too shared some concerns. Talking with him gave me some inspiration to start the missing manual for the aura framework.

The goal of the book it to provide a good resource for people to learn about the framework/components and their use and to help promote Aura. The book is available for free either on Github or Leanpub (or, to help support Hari and the project consider purchasing a copy).

In a recent post to his site Paul Jones shares some work that's been done to help generate books in the Leanpub formatting with an Aura framework-based script.

One of the things that bothers me about some cli/console packages is how the commands you write with them end up being tightly coupled to the “framework” the package provides. [...] Most of the time I don’t need a “full console application” - I just need to read some input for the command, run my actual command logic, and send some output from the command. The Leanpub Sampler from Matthias Noback is an example of the kind of thing I usually end up doing in small or one-off projects.

The script makes use of the Aura.Cli component for console interaction then a custom object for the actual work. This completely decouples the CLI handling from the code to produce the resulting document. You can find out more about the Aura framework on the project's main site.

In a recent post the Aura PHP blog compares the "lightness" of two different micro-framework-oriented packages - Silex and Aura.Web_Project (of the Aura framework project.

Too many people, including the Silex article author, use absolute terms like “light” and “heavy” and “bloated”, instead of relative terms like “lighter” and “heavier” and “more bloated” and “less bloated”, to describe software. Any time someone uses an absolute term like that, you need to ask: “Compared to what?” [...] don’t know if the measurements in that article are valid or useful for defining “what makes a microframework” but they do provide a basis for comparison. I understand that some people think “measuring (size|lines-of-code|number-of-classes) is stupid and it doesn’t matter!” Maybe it is, maybe it’s not. [...] So, let’s go with that article and use its approach to make a comparison between Silex and Aura.Web_Project to see if my earlier claim, using the terms and measurements outlined by the Silex post author, is accurate.

The rest of the post outlines the steps that were taken to perform the measurements, the tools used check things like memory usage and the results. They compare things like:

• Total Package Dependencies
• Total Disk Usage
• Total Class Count
• “Actual Usage” Class Count
• “Actual Usage” Non-Comment Lines Of PHP Code

On the Aura Framework blog, they continue their look ahead at the coming version of another of the framework's components, the Aura v2 Router. The Aura framework is a decoupled, modular framework that focuses on minimizing dependencies.

Lately, we’ve been going over the migration of v2 packages from v1. Today, I’ll talk about the updated Aura.Router v2 package. While not an example of extracting a new package from an existing one, it has a couple of features that other routers don’t currently have, in addition to being truly independent and completely decoupled from any other package.

They focus on some of the basics (more detailed information can be found on the package page) of the package's new features and its focus on routing rather than dispatching. Sample code is included showing it in use. The examples show basic routing, routing by server values and attaching route groups. There's also a brief section about adding REST routes via an "attachResource" method call.

Continuing their series of "sneak peeks" at the coming functionality and features of the next generation of components from the Aura framework, their blog looks at the version 2 of Aura.Web. This component has been refactored because of the creation of the Aura.Dispatcher as well.

Aura.Web v1 took the parts of Solar related to web controllers and combined them into a single independent package. [...] In the Aura.Web case, it turns out extracting Aura.Dispatcher was the key to reducing the Aura.Web package contents. With Aura.Dispatcher, any object can be a controller, since it can dispatch to any method on any object (as well as dispatching to closures). In turn, there is no more need for the Aura.Web package to provide a base controller with interfaces for various implementations.

The rest of the post explains the two halves of the new Aura.Web version - the Request and Response - and what kinds of things are included in each. It also links each to the parts of the READMEs that deal with them, providing a bit more information.

On the Aura framework blog there's a new post with a sneak peek at Aura.Dispatcher to handle the mapping between names and objects to handle the given request. The Aura framework provides high-quality, well-tested, standards-compliant, decoupled libraries that can be used in any codebase. This means you can use as much or as little of the project as you like.

In the lessons learned post, I talked about how Aura was born of the idea that we could extract independent decoupled packages from Solar, and how in doing so, we discovered that some of those extracted packages themsleves could be further split into independent pieces. Previously, I wrote about Aura.Sql-v2, Aura.Sql_Query, and Aura.Sql_Schema as extractions from a single Aura.Sql package. Today, I’m going to talk about Aura.Dispatcher as a combined extraction from three separate packages.

He starts off with a look at dispatchers in general, noting that they're usually used with request routing but the concept isn't limited to just that. He points out that CLI dispatching, as it turns out, is a lot like web request handling. The component makes routing both sides equally simple and could also be used as something like a micro-framework router. The post finishes up with this concept, talking about the evolution from micro- to full-stack framework structures and how the component could help.

Paul Jones has an interesting post on his site today talking about how how your "framework of choice" will eventually fail even if there is long term support for it. He points to another article about trial and error and emphasizes that (as Richard Feynman has said) failures are just as important as successes.

When it comes to expanding a body of knowledge, the failures are just as important as the successes, perhaps more so in some cases. (Be careful here; they have to be “honest” failures, where you had some reason to believe in advance that it had a good chance of working.) So what is it about the “Pipe Dream” article [here] that impressed me? It is that the the author first signals his tribe membership by mentioning his “framework of choice”, then proceeds to try to do some work outside of that tribe.

Paul goes on to talk about the usefulness of stepping outside of your norm - your framework of choice - and getting a wider perspective on how others do things. He looks at some of the ways that current frameworks could fail in the future and figuring out how well it will deal with it when it does. He points out that several times the failure comes from "subsystem failures" and that systems that allow the swapping out of these components would handle things more gracefully. He gives the example of the Aura framework of this, being highly component-based.

On the Aura blog Paul Jones has posted a look ahead for the framework, looking specifically at what's coming in version 2 for the Aura.Sql and ExtendedPdo functionality.

In the lessons learned post, I talked about how Aura was born of the idea that we could extract independent decoupled packages from Solar, and how in doing so, we discovered that some of those extracted packages themsleves could be further split into independent pieces.

He gives the example of Aura.Sql compared to the Solar_Sql (from the Solar framework) and how certain things that they thought needed to be coupled actually didn't. In version 2 of the Aura.Sql component, they're taking this same approach and abstracting out things that don't actually need to be in the base class. This breaks it up into three packages - Aura.Sql-v2, Aura.Sql_Query and Aura.Sql_Schema. He gets into more detail in the rest of the post as to what the new Aura.Sql (v2) will still handle.

As Paul Jones mentions in his most recent post (pulled from the Aura blog), the Aura framework has some new releases of its component packages - specifically Input, Sql and View.

On the heels of last week’s slew of releases, we have three followups! The Aura.Input package got a feature-level bump to 1.1.0, with a new FormFactory. Thanks to Hari KT for championing that one. Aura.Sql is now at 1.3.0, due to lots of work from MAXakaWIZARD to provide SQLite- and PostgreSQL-specific query objects. Finally, the Aura.View package got a bugfix and is now at 1.2.1; it handles content-type negotiation better for those times when there is no Accept header.

If you'd like more information about the Aura framework, check out the project site or each of the packages that make it up. Aura is a decoupled set of components without additional dependencies.