Adding Custom Controllers to an Evolution 2 Project

One of the recurring questions during the Evolution 2 transition was how to stop pushing too much logic into Blade views. This article came from that moment: a practical demonstration of adding custom controllers so that PHP-side page preparation happens before the view is rendered.

The original example used a dedicated package and a custom TemplateProcessor. The exact implementation belongs to that period of Evolution 2, but the architectural idea still matters.

Why Controllers Help

Controllers keep complex logic out of the view layer. Instead of filling Blade files with conditionals, data preparation, and service calls, you perform that work in PHP first and pass the result into the view.

In the original article, this was presented as a way to move even further away from classic snippet-heavy rendering.

The Core Idea

The solution was based on replacing the default TemplateProcessor with a custom processor registered through a service provider.

public function register()
{
    $this->app->singleton('TemplateProcessor', function ($app) {
        return new SeriousTemplateProcessor($app);
    });
}

Once that custom processor is active, it can extend the document rendering flow and decide whether a page-specific controller should run before the Blade template is returned.

Hooking a Controller to a Template Alias

The example used the template alias to build a controller class name dynamically:

$className = 'Serious\Controllers\' . ucfirst($templateAlias) . 'Controller';
if (class_exists($className)) {
    $customClass = new $className();
    $customClass->render();
}

With this approach, a template alias such as test would map to a class like Serious\Controllers\TestController.

What This Gave the Project

• page-specific data preparation before the view is rendered
• a cleaner Blade layer
• a reusable main controller that child controllers could extend
• a predictable convention based on template aliases

That made the frontend architecture closer to what developers expected from a modern MVC-style workflow.

Package Structure Matters

The original implementation lived in a separate package. That was important: the controller classes, the custom processor, and the service provider stayed outside the theme files and could be maintained as a coherent unit.

In practice, that meant:

• a service provider to register the custom processor
• a replacement processor class extending the standard one
• a controller namespace such as Serious\Controllers
• a naming rule that connected a template alias to a controller class

Why This Was Better Than Pushing Logic into Blade

Views should stay focused on rendering. When a page template starts selecting data sources, transforming collections, and orchestrating conditional behavior, the template becomes harder to test and harder to understand.

Moving that preparation into controllers keeps the view simple and makes the project easier to extend later.

Video Demonstration

The original article embedded a short video demonstration showing the controller approach in action. Even without the video, the message is clear: once the render flow can call project-level controllers, the theme layer becomes much more maintainable.

How to Read This Pattern Today

This is an Evolution 2-era technique, not a prescription for every modern Evolution 3 project. Today, the framework and package structure are more mature, and the exact extension points may differ. Still, the design principle holds up very well:

keep application logic in PHP classes and keep the view focused on presentation.

That is why this article still deserves a place in the archive.