A small PHP framework with HTTP, console, ORM, migrations, views and validation support.

Maintainers

Package info

github.com/mathmpr/adige

pkg:composer/trentino-alto/adige

Statistics

Installs: 2

Dependents: 0

Suggesters: 0

Stars: 0

Open Issues: 0


README

Adige is a small PHP framework with a focused core around:

  • HTTP and console request handling
  • explicit routing with controller autodiscovery
  • a lightweight ActiveRecord ORM
  • file-based views
  • migrations and model validation

About

Adige is the second-largest river in Italy, it was and still is one of the most important rivers in the country since the Middle Ages. The river gives its name to the Trentino-Alto Adige region. The name of the project is just a tribute to the memories of a trip that one of the collaborators (@mathmpr) took to this region of Italy.

Release target

The current release target is 1.0.0-alpha.

At this stage, Adige can be described as a stabilized microframework for the current line:

  • small and focused
  • tested around its HTTP core, console flow, ORM, migrations and validation layer
  • suitable for small, controlled and serious projects

Important scope note:

  • Adige is not positioned as a general replacement for large, battle-tested frameworks
  • the current scope is best suited for small applications, internal tools, simple APIs and controlled production environments
  • the package baseline is now aligned for the 1.0.0-alpha distribution model

Public API and compatibility notes for this target are documented in:

Git rules

Let's try to use git in a professional way, for this we will establish some rules.

  • Try to never commit and push directly to the branch master or develop.
  • Branch models must follow a standard:
    • adjust - for general adjustments. EX: adjust/<component-name>/fix-number-of-params-for-bind-value
    • hotfix - When a bug is in master, we can make a branch directly from master and then make a pull request directly to master, just to fix some "urgent" bug. EX: hotfix/<component-name>/fix-regex-for-identify-routes
    • feature - when we upload the feature for the first time. EX: feature/<component-name>
    • enhancement - when we are going to make a code improvement or refactoring. EX: enhancement/<component-name>/new-router-system
  • When committing, always type a message about what is inside it in a reduced form.
  • When making a pull request, we always point our branch to develop (and unless it is a hotfix), and on a certain day of the week or month we move everything from develop to master.
  • Pull requests must have a description of what was done in the commits contained in it.
  • The pull request cannot be merged into the target branch until there is at least one approve on the pull request and all pull request conversations are resolved.

Goals

  • Study OO concepts.
    • What is an object and what is a class.
    • Understanding the public, private and protected access levels.
    • Differences between static and non-static methods. Understand the properties too.
    • How the concept of inheritance works.
    • How the interface concept works.
    • How the concept for abstract classes works.
  • Study the concepts of DDD.
  • Create a component for router to allow calls to the HTTP: GET methods; POST; OPTIONS; PUT; DELETE.
    • Study the HTTP method.
    • Understand how a router works. Study references laravel, yii2 and slim.
    • Implement something similar to the basics of slim allowing groups of routes.
    • Allow auto discover route based on URI.
    • Implement middleware.
  • Create base component to perform basic and dynamic operations on the MySQL database.
    • The input must be the query and the array with the data for any operation.
    • Study how a query builder ORM works
    • Implement a query builder.

Installation

Install the package in a consumer project with Composer:

composer require trentino-alto/adige

The package exposes its console entrypoint through Composer bin proxies:

vendor/bin/adige

This is the main command entrypoint of the framework.

Package consumption

Adige is now distributed as a Composer library.

The important runtime paths are:

  • package root: where the framework code itself lives
  • vendor dir: the consumer project's Composer vendor/
  • basePath: the consumer project root

The console launcher already passes the project root automatically:

Adige::run(null, getcwd());

If you start the framework manually, pass the consumer base path explicitly:

use Adige\core\Adige;

Adige::run(null, __DIR__);

Minimal web consumer

Example project structure:

my-app/
├── bootstrap.php
├── public/
│   └── index.php
├── controllers/
│   └── IndexController.php
└── composer.json

Example composer.json for the consumer project:

{
  "require": {
    "trentino-alto/adige": "1.0.0-alpha"
  },
  "autoload": {
    "psr-4": {
      "App\\": ""
    }
  }
}

Example bootstrap.php:

<?php

use Adige\core\Adige;
use Adige\core\App;
use Adige\core\BaseView;

return [
    Adige::VIEW_HANDLER => [
        'class' => BaseView::class,
        '__construct()' => [
            __DIR__ . '/views',
        ],
    ],
    Adige::ROUTER_HANDLER => [
        'class' => Adige\core\routing\Router::class,
        '__construct()' => [
            '@request',
            '@response',
            true,
            'index',
        ],
        'controllerNamespaces' => [
            'App\\controllers',
        ],
    ],
];

Example public/index.php:

<?php

require __DIR__ . '/../vendor/autoload.php';

use Adige\core\Adige;

Adige::run(null, dirname(__DIR__));

Example controllers/IndexController.php:

<?php

namespace App\controllers;

use Adige\core\controller\BaseController;

class IndexController extends BaseController
{
    public function actionIndex(): string
    {
        return 'Hello from Adige';
    }
}

Minimal console consumer

Once the package is installed, console commands run from the project root:

vendor/bin/adige
vendor/bin/adige migrate/create --name=create-users-table
vendor/bin/adige migrate/up

The recommended command flow is:

  • use vendor/bin/adige as the primary framework command
  • use it to start the built-in PHP server
  • use it to create and run migrations
  • use it to generate the optional project-root launcher

Examples:

vendor/bin/adige server/start
vendor/bin/adige migrate/create --name=create-users-table
vendor/bin/adige migrate/up
vendor/bin/adige install/index

If you want a project-root launcher, generate one after installation:

vendor/bin/adige install/index

That command creates ./adige in the consumer project root and the generated file resolves:

  • ./vendor/autoload.php
  • Adige::run(null, __DIR__)

The generated ./adige file is an optional shortcut. It does not replace vendor/bin/adige as the official package entrypoint.

Configuration notes

The current package defaults are intentionally small:

  • console controllers default to Adige\console\controllers
  • web controller autodiscovery should be configured explicitly through controllerNamespaces
  • bootstrap files are discovered from the consumer basePath
  • migrations default to <basePath>/migrations
  • .env is loaded from the consumer basePath first

Tests

The core test suite is based on PHPUnit.

Run the full unit suite:

vendor/bin/phpunit --do-not-cache-result tests/Unit

Run a single test file:

vendor/bin/phpunit --do-not-cache-result tests/Unit/Routing/RouterFindRouteTest.php

Current tests focus on framework contracts such as:

  • router matching and autodiscovery precedence
  • route parameter resolution
  • middleware short-circuit and failure handling
  • response normalization
  • HTTP request/response behavior without a real web server
  • migrations, validators and package/runtime path behavior