New features in Quantum 1.5

The Quantum version 1.5 is released (the core and the project at the same time) with major changes and improvements. This version called major because it includes new features, bug fixes, but more important it includes major code refactoring and unit testings...

Although lots of things were changed but almost all the back compatibilities were kept, so in the project level all the functionalities remain the same. Well.. not all but almost all… at least one thing has to be changed on old projects to match 1.5 version requirements.

So what exactly was added or changed, let’s go further…

As you remember before version 1.5 routes were simple arrays with following structure.

The new way of defining routes are follows.

As you can notice, the general structure of each route mostly the same, so no much refactoring needed for projects lower then version 1.5.

With “new routes” you can define one route for different request methods:

So this route will work when it’s requested with POST or with PUT methods.

It’s now possible collect routes under some logical scope called groups.

At the first glance, it looks grouping the routes does not give much benefits, except it’s just more visible now.. True! But grouping the routes is not meant for just grouping.. it’s also for something more..

Middlewares are layers functioning in between of the request and the application. Each middleware can perform several actions and then forward the request to next middleware up to the controller, or terminate the flow by redirecting to different route.

The next illustration will say more then just words…

Each middleware should contain the apply() method where you can manipulate with the Request data, allow to go forward (to the next middleware or to the App) or terminate the flow completely.
In the above example we just checked if the session contains the key "loggedin" and if so we have added new value to the $request and allow to go next (meaning to next middleware or the App), otherwise we have redirected to home url.

Well, let’s go back to our routes and apply the Auth middleware to the route group.

Now the Auth middleware applied to the route group, which is the same as we will apply it to each of the routes in group. So now the routes under the group "post" will not work if the condition inside middleware is not satisfactory.

You can apply a middleware to the specific route as well so it will work only for that route.

As you can see the admin middleware was applied only to one route, where the auth middleware is applied to all the routes inside the group.

This is a big term, and it’s not about to allowing you to create your own dependency injection containers.. not in this version, but due to major refactoring it’s now possible to have the $request available inside controller's action, in other words make the actions dependents from $request.

Remember on versions < 1.5 the Request params inside the action were accessible via Request class (and still can be).

Now as the $request was injected into the controller's action, you can do it like so:

Remember that the initial $request can be modified inside the middlewares before it will reach to the action.

Related posts:

The journey of product development is not without moments of doubt. But there is a way to experience a breakthrough and see your new idea come to fruition. Bringing your idea to market requires both…

In this second part of the previous introductory article, we’ll tackle the more in-depth description of data collection, object modelling, and data analysis at CMS. The general workflow behind these…

Having completed training in July of this year, the soldiers of the UK Task Group donned the famous blue UN beret on Salisbury Plain in October as they underwent final assessment. The troops were put…