On his blog today Hari KT has an Aura Framework-related post about one of its components, the Aura.Http component, and its handling of HTTP requests and responses.

The Aura.Http package provide you the tool to build and send request and response. [...] Probably you may not have bothered too much on building the http response either the framework does it for you, or until you need to send the correct response.

The post shows you how to use the component to send and receive HTTP requests. Code is included showing how to make Response objects and set headers, content, cookies and HTTP response code. He also shows how to output the response and a more complete example of the entire flow. The post finishes up with an example of using Aura.Http to make a request to another site - in this case back to GitHub to get the users on a repository.

The Aura framework project has released a set of updates to several of their packages including the main Aura.Framework and Aura.Demo functionality.

Late last night we released version 1.0.0-beta4 of the full-stack system, which composes all the independent Aura packages into a coherent framework using the Aura.Framework package in a project skeleton. We have extracted the "hello world" portions into their own Aura.Demo package so that it can be removed or disabled when you begin your project. Download it and take it for a spin!

There's been a lot of talk recently about the Aura framework and its "less dependencies, more separate packages" approach to making the framework including these posts from Paul Jones and others.

On the Web Mozarts blog there's a recent post from Bernhard Schussek looking at some of the recent talk about dependencies in the PHP community sharing some of his thoughts on the subject and the Not Invented Here thought pattern.

The general attitude of people arguing against dependencies is that dependencies are a bad thing. Why could they be a bad thing? [...] Why do libraries have dependencies at all? Is a library with dependencies less decoupled than one without?

He includes some of the common reasons dependencies might be a bad thing (including maintenance issues and space concerns) as well as comparing two similar concepts - "coupling" versus "cohesion".

What does this mean in practice? Can we just increase the amount of dependencies as we like? My personal stance on this topic is that a library should require as little as possible dependencies to run (hard dependencies) - as long as it is highly cohesive - but support as many different libraries as it can (optional dependencies).

In response to the number of questions (and popularity) of his previous information about the Aura framework and how it compares to Zend Framework 2 (and Symfony2), Paul Jones has posted more about its decoupled nature and how the frameworks compare.

Being able to use Symfony2 components or ZF2 modules is not quite the distinction I am making. The distinction is that all Aura packages (with the exception of the Framework package) are completely independent, and have no cross-package dependencies, whereas at least some of the components from Symfony2 and ZF2 have dependency requirements.

He illustrates the point with a common task across all of the frameworks - input validation and filtering. He starts with a look at how to handle it in Zend Framework 2 (with Zend/InputFilter) with the list of packages also pulled in by the Composer install. He does the same with the Symfony2 "Validator" package and mentions the other packages needed to execute its tests. Finally, he looks at Aura's "Aura.Filter" component and it's lack of dependencies (and that its tests can be executed immediately).

In this new post Paul Jones has reprinted an interview he did with PHP Magazin about the recent 1.0 release of the PHP framework project he is a lead on - the Aura project.

I did an email interview with the folks at PHP Magazin; their German version is here. What follows is our original email exchange in English.

They talked about some of the core principles behind the framework, its origins from the Solar framework, the team's "libraries first, framework second" methods and its push to be a PHP 5.4-focused framework. There's also a bit that compares the framework to two other popular options - Zend Framework and Symfony.

As Paul Jones mentions in this new post to his site, the Aura Framework project has just released it's 1.0 stable version of all of its packages. The Aura project provides independent library packages for PHP 5.4+. These packages can be used alone, in concert with each other, or combined into a full-stack framework of their own.

The Aura Project for PHP 5.4 is happy to announce its first release of 1.0.0 stable library packages. [...] In addition, we have initial beta releases of four new libarary packages. [...] While the above packages are completely independent of each other, Aura also has a Framework package that binds them all together.

Packages included in the v1.0 of the framework include Aura.Cli, Aura.Http and Aura.Signal. Beta packages are things like Aura.Filter and Aura.Intl.

You can find out more about the project from its site over on github.

The Aura Framework project has made a new post to their blog walking you through the steps you'll need to contribute back to the project with your ideas and bugfixes for their various components.

Sometimes you may have noticed a bug, or need a feature implemented, and need to contribute back to the aura community. These are some of the steps to help / contribute to aura project.

They walk you through: setting up git (well, point you to github's guide), fork the main repository and check out a copy, creating a remote to the "upstream" (main) repository and pulling the latest content from it into your fork. Included are the commands to run PHP_CodeSniffer and PHPUnit with the provided tests. From there, it's up to you and your code to contribute back, commit and make a pull request!

On PHPMaster.com today there's a new tutorial showing how to route your web requests with the Aura.Router component from the AuraPHP component framework.

Everyone is interested in SEO-friendly, REST-style URLs. Apache can do URL routing via mod_rewrite rules, but it's hard and error prone. Why not use PHP itself to handle routing instead? Aura is a independent collection of libraries for PHP 5.4 brought to you by Paul M Jones. Here we are going to introduce you Aura.Router. Aura.Router is a simple and easy web routing library for PHP. In this article you will learn how to create routes which are SEO-friendly, REST-style URLs with the help of PHP.

He walks you through the download and install of the Aura.Router component (separate from the framework) and how to set up the mod_rewrite rules to work with it and a front controller. He includes some code for a basic usage, showing the mapping of a default route and more complex routes with named parameters. He also shows how to use the "match" method to find the route that was matched and how to dispatch/hand off the routing to a controller.

Hari K T has a new post to his blog that shares his concern about a "design flaw" in the component/package methods promoted by Symfony2 and Zend Framework 2:

Looking from outside both Symfony2 and ZF2 is full of standalone components. But the reality is not the same. Though Symfony2 components are split into each components in github, you cannot give a pull request to that component. The tests for all the components still resides in the core.

He points to the Aura framework project as a good example of how to make a truly component-centric set of tools complete with tests bundled into the component's download right next to the source.

As Paul Jones mentions in this new post to his blog the Aura project, a PHP framework, originally targeted at PHP 5.3 has changed its direction a bit - they've shifted from a focus on PHP 5.3 to the upcoming PHP 5.4 release.

When I initially announced the Aura project, it was targeted at PHP 5.3. With a stable release of PHP 5.4 impending, we have moved the target to PHP 5.4. In addition, we have made 1.0.0-beta1 releases of almost all the component packages. (See an earlier announcement from Hari KT.)

The components include: a dependency injection container, an autoloader and a view system that are all self-contained with no other dependencies. You can find the complete code for these containers (and one for combining them all into a single system) on the project's github page.