DEV Community: Thierry Feuzeu

Jaxon DbAdmin: PHP finally gets a next-gen database manager

Thierry Feuzeu — Thu, 08 Oct 2026 01:42:05 +0000

The PHP ecosystem has gifted the IT world with two of the most widely used open-source database management tools: Adminer and PhpMyAdmin, each having millions of monthly downloads. However, newer solutions have emerged to provide advanced features that these traditional tools do not natively offer, such as simultaneous multi-database browsing, data masking, advanced users and credentials management, audit logging, and modern UI/UX. Alternatives like DBeaver, DbGate, ByteBase, and the more recent Tabularis and DBx, just to name those with an open source license, deliver these capabilities. Available as web or desktop applications, their user interfaces are built using modern JavaScript frameworks like React.

Today, the Jaxon DbAdmin web application bridges this gap.
It positions itself as a modern database management tool built with PHP, delivering the same high-level features as the most advanced alternatives on the market. While the foundational 0.32.0 release introduced an extensive list of changes, fixes, and architectural improvements, subsequent releases have refined the platform. The features highlighted in this article are available in version 0.35.1, the latest release at the time of writing. Finally, we will also take a look at the main features planned for upcoming releases.

The Jaxon DbAdmin applications

Jaxon DbAdmin is provided as a Jaxon package, which means it implements both the application backend and frontend, and it needs to be installed in an application framework.

Read the features and current status.

The previous Jaxon DbAdmin releases shipped with a single ready-to-use application built with Laravel. There are now three of them, respectively built with the Laravel, Symfony and Slim PHP frameworks.

Read the installation documentation.

The user management and authentication feature in Jaxon DbAdmin is provided by the framework it is installed on. Supporting multiple different frameworks then allows the users to choose their preferred authentication strategy and tools, depending on their needs. The Laravel, Symfony and Slim frameworks are able to implement various user authentication strategies, from the most simple to the most advanced.

The Jaxon DbAdmin applications include a default authentication feature where the user accounts are stored in a database for Laravel and Symfony, or in a json file for Slim.

Read the default authentication documentation.

Althought they are based on different frameworks, the Jaxon DbAdmin applications share the same configuration options and files.
The config options are separated into three files, app.php, servers.php and foreigns.php. In the app.php and foreigns.php config files, some options values are provided as closures or anonymous classes.

The servers.php file can also be provided in json or yaml format. In that case the file is renamed to servers.json, servers.yaml or servers.yml.

Read the configuration documentation.

The Jaxon DbAdmin Docker images are also updated, and they are now tagged both with the framework name and their version number.

Database secrets management

The previous releases already allow the users to store their database credentials in a secret management server, instead of the default .env.dbadmin file.

The latest release now natively supports 6 secret management services:

Infisical
AWS Secrets Manager
GCP Secret Manager
OpenBao (compatible with HashiCorp Vault)
Azure Key Vault
Alibaba Key Management Service

Using a secret manager requires two options in the app.php config file.
The secret.reader option defines the name of the class implementing the service client, and the secret.key defines a class with a function returning the secret location for a given user.

    'secret' => [
        'reader' => Provider\Secret\InfisicalConfigProvider::class,
        'key' => fn() => new class implements Provider\Secret\KeyBuilderInterface {
            public function build(string $prefix, string $option = ''): string
            {
                // $username = Auth::userId(); // Use this to customize the key.
                return "users.{$prefix}.{$option}";
            }
        },
    ],

Each secret manager also defines custom options to be provided in the .env.dbadmin file, and optionally a procedure to setup the client.
Jaxon DbAdmin will query the secret service for database credentials on each user request, and will never save any secret locally, not even in a cache.

Read the secret service configuration.

Multi-tab navigation

The list of database servers a Jaxon DbAdmin user can connect to is configured on the server. That list can be customized for each user, and the servers he is allowed to connect to will be displayed in a dropdown list.

Jaxon DbAdmin allows the user to open multiple tabs, each connected to a chosen database. Each tab can be renamed, and by default a tab is named after the database it is connected to. Connecting to a different database automatically rename the tab accordingly.

When connected to a database, the Query Editor window also allows the user to open multiple tabs. It is convenient when the user needs to run multiple queries on the same database.

The application window and Query Editor tabs can be saved in the user preferences. They will the be automatically recreated anytime the user opens the application.

The Query Editor and Query Builder

Similar to Adminer, Jaxon DbAdmin provides two tools to query database tables: the Query Editor and the Query Builder.

The Query Editor allows the user to manually edit, then execute SQL queries. As stated earlier, multiple editor tabs can be opened on the same database. The user can also choose its preferred editor between the CodeMirror 6 and Ace.

In addition to SQL syntax highlighting and code completion, the Query Editor also provides code completion on the connected database tables and columns names.

The Query Builder is a visual builder for database queries, which also supports querying and editing table data, and editing table definition.

The Query Builder displays the selected table rows in a paginated list. Various buttons and dialogs allow the user to select the columns to be displayed, filter rows on column values, and change the results ordering. The corresponding SQL query is displayed in a read-only field, with syntax highlighting enabled.

Each data row can be edited in a dialog where each column value is displayed in an HTML input field corresponding to the column type.
The same dialog can be use to insert a new row in the table.

The Query Builder can also display a table definition, in a page with the table columns, indexes, foreign keys and triggers. From there, the table definition can be altered, in a page that will allow the user to change the table name and properties, and edit, delete or add columns in the table.

When editing row data or table definition, the corresponding SQL query can be displayed for prior validation, and even copied to the Query Editor.

The foreign keys

In the paginated list of rows of a table, when a column is a foreign key, each value is displayed in a link. A click on that link will move the page to the referenced table, and add a filter on the referenced column and value, so only the referenced row is showed.

When a table has one or more foreign keys, a toggle button labelled Foreigns is added on the page. When this button is enabled, the values from the first column with a string type in the referenced table are fetched and displayed instead of the actual column values.

The SQL queries for fetching the referenced values can be customized in the foreigns.php config file.

return [
    'dbadmin-mariadb' => [
        'employees' => [
            'employees' => [
                'emp_no' => [
                    'select' => fn(int $textLength) => "SUBSTR(CONCAT(first_name, ' ', last_name), 1, $textLength)",
                    'search' => fn(string $search) => "LOWER(first_name) LIKE $search OR LOWER(last_name) LIKE $search",
                ],
            ],
        ],
    ],
];

Read the foreign fields documentation.

File storage for database import and export

The database import and export function rely on the FlySystem package for file storage. They are then able to store the SQL files on a any of the supported storage types.

The SQL files locations are user dependent, which means a user cannot get access to another user files from his account, event when knowing its name. This also apply to the file URL for database export. It is valid only for the user who made the export.

Read the data import and export documentation.

Input streaming in database import

Generally, the imported files are loaded into the application memory before the SQL queries they contain are executed. The application then needs to have enough available memory to be able to store the entire file. In Adminer for example, the PHP memory limit is updated when processing the imported file.

Jaxon DbAdmin introduces a new Query Processor, with a new file processing model where the file lines are streamed in input, and the corresponding queries are streamed in output. This results in a dramatic reduction in memory usage, since only a few input lines and a single SQL query are kept in memory at the same same time.

This screenshot shows how the lines stream in and the queries stream out the Query Processor, on a few lines file.

While sequential execution within the new Query Processor can increase total execution time, this challenge is easily solved by modern PHP architectures. By leveraging framework workers, time-consuming queries can be handled asynchronously. This feature will be introduced in an upcoming release.

Audit logging

Jaxon DbAdmin can be configured to save all the executed queries in a dedicated database. These queries can then be visualized in a separate audit logging page with restricted access.

The latest releases feature an extension of the data Jaxon DbAdmin records in the audit logs. They now include the client IP, the user agent, and generated ids for the HTTP session and request, the database driver and options, the query code, result, timestamp and duration, the error code and message when the query execution fails, the number of returned or affected rows when the query execution succeeds, and of course, the user who executed the query.

Note: some of the fields still need to be filled or displayed in the audit logs page.

The new application architecture

Although running behind the scenes, the new application architecture is the foundation designed to make the implementation of all other features both simple and reliable.

The database drivers

Since its early releases, the database features are implemented in separate packages:

https://github.com/lagdo/dbadmin-driver: common classes and interfaces for the database drivers.
https://github.com/lagdo/dbadmin-driver-pgsql: the database driver for PostgreSQL.
https://github.com/lagdo/dbadmin-driver-mysql: the database driver for MySQL and MariaDB.
https://github.com/lagdo/dbadmin-driver-sqlite: the database driver for SQLite.

Today, the drivers have evolved to a simpler model where their features are separated into query generation and query execution. The query execution part takes a raw query as input, passes it to the database server, and, depending on the query type and the execution results, returns the appropriate set of data.

With the exception of a few specific cases, the DDL, DML and DQL functions now generate and return a set of SQL queries, which will then be executed in a separate call. Prior to execution, the generated query can be presented to the user for validation, editing, or even storage for future reuse.

The usage of DTOs has also been generalized. Instead of arrays or strings, the drivers functions now receive DTOs as input and returns other DTOs as output.

As stated before, the database features come from Adminer. It means that the actual calls to the database servers, for example to read the list of tables in a database, still run code inherited from Adminer. That code is eventually improved to adapt to PHP 8 changes, and return data in DTOs instead of arrays.

The database support layer

On top of the database drivers, a pluggable support layer is introduced, with many new features. The timer for query duration computation and audit logs storage are modules that are plugged into the driver proxy, and automatically called before and after every query execution. They take the query SQL code and results as parameters.

In addition to the drivers DTOs, another set of DTOs is provided to carry the data between the UI components and the driver. So a database function now takes the user data as input in a UI DTO, converts it to a driver DTO, calls one or more driver functions, and converts the output to another set of UI DTOs. As a result, from the UI to the driver, every Jaxon DbAdmin feature processes well-defined and strongly-typed data structures, which significantly boosts reliability.

At the core of the query execution feature, a new QueryProcessor class is introduced, serving as the only interface for query execution. It takes a set of queries in a DTO as input, calls the driver functions, and returns the results as a set of DTOs. It also accepts options allowing callers to decide whether to log queries or compute execution duration. In such cases, the corresponding features are enabled in the classes where they are implemented.

Another notable change is the QueryStream class, which allows the database import feature to stream uploaded file lines instead of loading them all at once into memory.

Oncoming features

AI assistant

The AI assistant is on top of the next releases feature list.
Two interaction modes are planned. The Ask mode where the AI assistant can suggest SQL queries without actually executing any of them, and the Agent mode where it can also execute queries.

The Jaxon DbAdmin drivers are able to return detailed data about the database tables and columns. Combined with the Query Processor unique features, there form a solid basis for the AI assistant implementation.

Enhanced query builder

Currently, the Query Builder builds select queries only for a single table. In the future releases, it will be able to query multiple tables with joins, and convert complex select queries from SQL code to its internal data structure.

UI templates

The application UI is built with the UI Builder library. Three Bootstrap 5 templates are currently available, built from the open source SbAdmin, CoreUi 5 and Plain Admin dashboard templates.

Other CSS frameworks are planned to be supported by the UI Builder library, including TailwindCSS and Bulma. So in addition to Bootstrap 5, other templates based on these frameworks will be available in the future releases.

Integrating a new admin dashboard is easy, since it doesn't require any changes to the application UI components code.

Closing thoughts

The latest releases of Jaxon DbAdmin introduce an extensive array of new features and improvements. On top of the existing database driver packages, a new engine for query generation and execution has been deployed, boosting reliability thanks to the use of DTOs. On the UI/UX front, the usability of every function has been significantly enhanced.

With its current roadmap, Jaxon DbAdmin will soon match the feature set of the market's most advanced solutions, such as DBeaver, DbGate, ByteBase, and the more recent Tabularis and DBx. It will even offer a superior alternative in certain areas, such as its database credentials management and native support for multiple secret managers. While alternative tools often restrict advanced features to paid plans, Jaxon DbAdmin offers all its functionalities completely for free.

Unlike these desktop-centric alternatives, Jaxon DbAdmin is a pure web application written in PHP, like Adminer and PhpMyAdmin. It therefore combines the security and centralized advantages of a server-side web application with the usability of a desktop client.

A real world case of recursion done right in PHP

Thierry Feuzeu — Sun, 20 Sep 2026 09:51:49 +0000

Nick Cosentino @DevLeaderCa posted this message about recursion on X, ex Twitter, in October 2025, which received over 460 replies.

// Detect dark theme var iframe = document.getElementById('tweet-1984123215170421060-448'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1984123215170421060&theme=dark" }

I quote an excerpt: I've found that converting over to an iterative loop based approach is almost always more readable and easier to debug. He explains that in over 20 years of programming, he has never used recursion, thus questioning its usefulness.

In this article, I show a real case where I used recursion, and where I think that it is much simpler than its iterative counterpart.

But before going any further, let see what makes a recursive algorithm powerful.

The Fibonacci sequence

To understand the value of recursion, let's look at the implementations with and without recursion of an algorithm very often used to illustrate it: the Fibonacci sequence.

Here's the recursive algorithm.

if n = 0 or n = 1 then
    fib(n) = 1
else
    fib(n) = fib(n − 1) + fib(n − 2)
endif

And here's the iterative one.

if n = 0 or n = 1 then
    fib(n) = 1
else
    a = 1
    b = 1
    for i in 2 .. n do
        c = a + b
        a = b
        b = c
    endfor
    fib(n) = c
endif

This simple example demonstrates the advantages of recursion: no loops and no intermediate variables.

This also gives us an indication of when recursion is advantageous, namely when the function can be defined with a simple expression depending on itself. This might not be the case for example when the data being processed is a graph instead of a tree.

Our problem

The library we'll be talking about is the PHP UI Builder. It builds application UIs using components, as defined by CSS frameworks. It provides a common API which defines the components, and from which specialized libraries can generate HTML code for a given CSS framework, like Bootstrap, Bulma or Tailwind CSS.

The UI components

With its hierarchical component structure, a UI is particularly well-suited to a recursive algorithm. A component has properties, but can also contain components that themselves have some properties and can contain other components, and so on.

The virtual components

When building a UI from data, the result can sometimes vary depending on their values. Some components will only be created under certain conditions, others are multiplied according to the entries in a list or loop, and others may be an aggregate of different components.

To represent these cases, our library introduces the concept of virtual components. These are components that take a set of data as input and produce as output a set of zero or more components, which may or may not be virtual.

There are 4 of them:

When: takes a condition as input and generates a component if it is met.
Each: takes an array of data as input and generates a component for each element.
Pick: takes a list of conditions as input and generates a different component depending on the first one that is true.
List: aggregates any set of components into one.

A UI will ultimately consist of a tree structure of components, each of which can be virtual or real. A real component can have several children, each of which can be virtual or real, and a virtual component generates a list of components, each of which can be virtual or real.

Here's an example of a function using the UI library.

/**
 * @param array $collations
 *
 * @return string
 */
public function addDbForm(array $collations): string
{
    return $this->ui->build(
        $this->ui->form(
            $this->ui->row(
                $this->ui->col(
                    $this->ui->label($this->ui->text('Name'))
                        ->setFor('name')
                )->unit(1, 4),
                $this->ui->col(
                    $this->ui->input()
                        ->setType('text')
                        ->setName('name')
                )->unit(1, 2)
            ),
            $this->ui->when(count($collations) === 0, fn() =>
                $this->ui->input()
                    ->setType('hidden')
                    ->setName('collation')
                    ->setValue('')),
            $this->ui->when(count($collations) > 0, fn() =>
                $this->ui->row(
                    $this->ui->col(
                        $this->ui->label($this->ui->text('Collation'))
                            ->setFor('collation')
                    )->unit(1, 4),
                    $this->ui->col(
                        $this->ui->select(
                            $this->ui->option('(collation)')
                                ->setValue('')
                                ->selected(true),
                            $this->ui->each($collations, fn($_collations, $group) =>
                                $this->ui->pick(
                                    $this->ui->when($group === '', fn() =>
                                        $this->ui->each($_collations, fn($collation) =>
                                            $this->ui->option($collation)
                                        )
                                    ),
                                    $this->ui->when(true, fn() =>
                                        $this->ui->optgroup(
                                            $this->ui->each($_collations, fn($collation) =>
                                                $this->ui->option($collation)
                                            )
                                        )->setLabel($group)
                                    )
                                )
                            )
                        )->setName('collation')
                    )->width(6)
                )
            )
        )
    );
}

The processing algorithm

To generate a UI from a component tree, we will use the following algorithm:

function build(c)
    children = []
    expand(c, children)

    c.elements = []
    for child in children
        if child is a component then
            build(child)
            append child.elements to c.elements
        else
            append child to c.elements
        endif
    endfor
endfunction

function expand(c, children)
    if c is virtual then
        for child in c.children
            expand(child, children)
        endfor
    else
        append c to children
    endif
endfunction

What we have here is actually a combination of two recursive functions.

The expand() function returns the list of real components generated by a virtual component. It will therefore iterate recursively over all its children as long as virtual components are present.

The build() function, which is the entry point for the process, first calls the expand() function. Its list of children then consists only of real components, on which it executes recursively.

The final result is in the Scope class. In their PHP implementation, the recursive expand() function is 15 lines of code long, and the build() function is 40.

Two extremely simple functions, which form the basis that allows the implementation in a single library of both the templating functionalities of libraries such as Twig or Blade, and the HTML code generation of libraries such as Spatie's HTML Builder or Symfony's Forms component (the rendering part).

The UI library is used to build the Jaxon DbAdmin UI, demonstrating that it allows the construction of complex UIs, calling classes and their methods instead of writing HTML templates.

The limitations of recursion

Nick Cosentino's message rightly points out two drawbacks of recursion, which we will briefly discuss here.

Debugging

First, it's absolutely true that recursion is difficult to debug, particularly because mentally unraveling the instructions executed by a recursive algorithm is very complex. However, at the same time, the simplicity of recursive algorithms leaves little chance for a bug to occur.

Therefore, before choosing recursion, it's important to ensure that the algorithm being implemented can be expressed very simply in a recursive manner. This is indeed the case for the Fibonacci sequence and our library.

Memory usage

Implementing a recursive algorithm can consume a significant amount of memory, depending on the level of nesting of the calls.
For our UI library, the level of nesting of an application's UI components will always be very limited, and even more if it is built one part at a time, each in a separate recursive function call.

Moreover, PHP imposes a limit on the number of nested calls within a recursive function, and the consequence of an overflow will be to fail a single call, not to crash the entire server.

The closing word

To answer Nick Cosentino's initial question, of course it is possible to create all sorts of complex software without using recursion.

However, this doesn't mean it can always be replaced by an iterative version, but rather that cases where one can fully leverage all its advantages are not very common.

What if we improve the way developers are given access to databases

Thierry Feuzeu — Fri, 03 Oct 2025 18:00:41 +0000

Developers often need direct access to the databases used by the applications they work on, in virtually every environment of a project: development, testing, pre-production, and sometimes even in production.

To do this, they use software such as Adminer, PhpMyAdmin, DBeaver, and many others, which share a common feature: they authenticate their users with database access parameters.
This pushes teams within companies to share database access credentials with developers, which, in the best-case scenario, is done with a password manager software.

This sharing of database credentials can pose several risks.
Accidental leaks of sensitive information, if a developer inadvertently shares this data with third parties.
Reuse of credentials in inappropriate environments.
Uncontrolled and untraceable access, due to the sharing of this information with multiple developers.
Access by unauthorized individuals, when developers leave the company.

Enforcing good security practices under these conditions will be difficult.

Jaxon DbAdmin

Jaxon DbAdmin is a web-based database management application that takes a different approach to user authentication and database connection.

The application clearly separates the authentication of its users and the connections to databases. The parameters of the later are stored only in its configuration file on the server.

When a user logs in, Jaxon DbAdmin reads the list of databases they have access to from its configuration and presents it to them.
And when the user performs an action on a database, Jaxon DbAdmin reads the corresponding database credentials from its configuration, executes the action, and returns the result.
This allows the user to access the database contents without having access to the database credentials.

It's worth noting that this database access technique isn't exactly new.
On the one hand, applications that use databases already store database credentials this way, and on the other, there are already database management applications that authenticate their users elsewhere than in the database.
Jaxon DbAdmin combines these two approaches to make it its default mode.

Jaxon DbAdmin is an open source software distributed under the BSD-3-Clause license: https://github.com/lagdo/dbadmin-app.
A Docker image is also provided: https://hub.docker.com/r/lagdo/jaxon-dbadmin.

Jaxon DbAdmin is still actively developed, and some features are not yet available.

The advantages

Storing database credentials on the server only enhances security.
Developers cannot copy, transfer, or expose credentials, even by mistake.
Each request can be linked to a specific user or role, making it easy to audit who did what, and when.
Login credentials are no longer scattered across development workstations, in configuration files, emails, or other communication tools. They can even be secured in a vault.

Connection configuration is now managed at the platform or infrastructure level, not in the application code. This makes it easier to manage environments (dev, staging, production).
Since users don't have access to the database credentials, they can be changed regularly without disrupting applications or developers.
Similarly, if the credentials are compromised, the administrator won't have to change them on developer workstations. This is done in a single location, transparently for applications and users.

There will also be better permission management based on the principle of least privilege: each user only has access to what he needs, regardless of the database credentials actually used.
If a developer leaves, his access to the application can simply be revoked, without having to change the database password and impact all other applications and users.

Finally, many security standards require strict data access management.
Not sharing database credentials makes it easier to comply with these requirements.

The challenges

Despite the above advantages, the use of existing tools that offer separate authentication is not common enough because it faces several challenges.

Setting up and using a secrets management system (vault) or an API Gateway with the necessary permissions is complex. For a small team or on certain projects, this represents a significant overhead in terms of time, skills, and budget.
On the other hand, tools such as DBeaver (Community) and Adminer are free and open-source.

Certain complex tasks (analyzing indexes, optimizing queries, performing large-scale exports/imports) are much simpler with a graphical tool than with a command line or REST API.
The same is true for analyzing the structure of a complex database with many tables.
The user-friendliness of the graphical interface of tools like DBeaver or Adminer is a definite advantage.

Experienced developers sometimes like to have direct control over the database.
They appreciate the speed of an ad hoc SQL query to explore a database schema, understand relationships between tables, or test complex logic before writing it in code.
For occasional manipulations, connecting with a graphical tool seems faster.

It is difficult to replicate an environment where direct access to the database is prohibited on a development workstation.
Developers then need a local database to code on, and in this case, access security isn't a priority.
Adminer or DBeaver are ideal for this, and the temptation is great to use the same tool for all environments.

Many developers have always worked with direct database access.
In many companies, sharing database access credentials is a historical and culturally entrenched practice. Changing this requires shifting processes and mindsets.
Furthermore, not all developers are aware of the risks or alternative best practices.

In conclusion

Jaxon DbAdmin is a web-based database management application that separates user authentication and database connections, meaning that database credentials are not shared with users accessing them.
Its configuration allows the administrator to define credentials for each user or group of users.

It will therefore improve the security of access to databases, while maintaining the user-friendliness and simplicity of a graphical interface.

Its code comes from Adminer, which has been refactored and modernized. Although its UI has also been modernized, it offers similar functions as Adminer.

However, Jaxon DbAdmin is still actively developed, and some features are not yet available.

Announcing Jaxon version 5

Thierry Feuzeu — Thu, 25 Sep 2025 17:44:56 +0000

This post was originally published on the Jaxon blog.

After more than two years of development, the version 5 of the Jaxon library is finally out!

This release is an important step that I think will bring the Jaxon library to the next level, because it implements the features I hoped the library had when I started developing and using it more than ten years ago.

So what's new in this release?

Exported PHP classes are now called components, and they can be of three different types. Some components can be attached to DOM nodes, and used to set their content.
The call factories in PHP have been enriched, and now support calls to Javascript functions and event handlers, as well as their parameters.
The command names and formats in responses are now more meaningful, and their processing in Javascript is improved. Deprecated commands have also been removed.
The dialog libraries now contain only Javascript code, in a single and tiny object. They will therefore be much easier to create and maintain.

Now let's dive more in depth into each of these new features.

The Jaxon components

In the previous versions of Jaxon, the webpage content was set exclusively using the HTML id attribute.

$this->response->html('dom-element-id', $text);

Each DOM element with dynamic content in a webpage content needed to be given a unique id, which will then be used to update its content. Keeping track of all those ids in an application was not an easy task.

Jaxon 5 introduces a new UI component, which is a Jaxon class that defines the content of a DOM element.
It just needs to implement a method named html(),

namespace Jaxon\Demo\Calc\App;

class Calc extends \Jaxon\App\NodeComponent
{
    public function html(): \Stringable
    {
        return $this->view()->render('jaxon::demo::calc::calc');
    }
}

and to be bound to a DOM element in a webpage.

<div <?= attr()->bind(rq(Jaxon\Demo\Calc\App\Calc::class)) ?>>
</div>

The render() method in the component can then be used to set the DOM element content, for example with an event handler.

    <button type="button" class="btn btn-primary" <?=
        attr()->click(rq(Jaxon\Demo\Calc\App\Calc::class)->render()) ?>>Clear</button>

In this example, a click on the button will display the jaxon::demo::calc::calc view in the div element the UI component is bound to.

The new components now make it very easy to build complex UI with Jaxon.

The call and selector factories

Since one of the core features of Jaxon is to write UI components code in PHP on the server, it is important to be able to make calls to Javascript functions, define event handlers, and last but not the least, pass the contents of the webpage as parameters to those calls.
That's the role of the call factories.

The call factories have been around since the version 2, initially as the JQuery PHP API.
They have evolved a lot since then, and now they can make calls to the exported Jaxon classes, or to any Javascript function or object.
They can also define event handlers on the webpage elements using Javascript or JQuery-style selectors.
Thirdly, they also provides functions to pass any content of the webpage as parameter to Javascript calls.

In this code from the Jaxon examples, JQuery selectors are used in a Jaxon custom HTML attribute to define calls to Jaxon classes as event handlers on two select lists, and to pass the selected item value as parameter to the handler.

    <div class="row" <?= attr()
        ->select('.app-color-choice')
            ->on('change', rq(AppTest::class)->setColor(jq()->val()))
        ->select('.ext-color-choice')
            ->on('change', rq(ExtTest::class)->setColor(jq()->val())) ?>>

In this other example, a command is added in a response to make a call to the Tontine.makeTableResponsive('content-planning-charge-page') Javascript code in the browser.

    $this->response->jo('Tontine')
        ->makeTableResponsive('content-planning-charge-page');

When building an application UI on the server, being able to make Javascript calls and set event handlers in a webpage is paramount, and the call factories provide Jaxon with a powerful set of features to achieve that quite easily.

Javascript library rewrite

The Javascript library rewrite started as a discusion on Github about the forbidden usage of the eval function.

I then decided to rewrite the Javascript library, which today has resulted in many important changes.

The library now includes a command processor which executes existing Javascript functions from a JSON payload. With this processor, there's no need for the eval function anymore, and it is also at the foundation of the call factories described above.

The library also includes an attribute processor, which handles the Jaxon custom attributes needed to implement the UI components bindings and the event handlers.
In the example above where the Jaxon\Demo\Calc\App\Calc UI Component is bound to a div element, the following HTML code is actually generated.

<div jxn-bind="Jaxon.Demo.Calc.App.Calc">
...
</div>

The response commands were also rewritten with new names and a new JSON format. Their names are now more meaningful, and the obsolete ones were removed.

The Dialog plugin

The Dialog plugin is a special case in the Jaxon universe. It is a Jaxon response plugin, but at the same time it can also be extended with it own plugins.

In the previous version, adding a dialog plugin required to write functions in both PHP and Javascript.
In the v5 release, only a tiny Javascript object is now necessary.

This is for example the code of the Notify library integration, which implements the alert function.

jaxon.dom.ready(() => jaxon.dialog.register('notify', (self, options) => {
    // Dialogs options
    const {
        alert: alertOptions = {},
    } = options;

    const xTypes = {
        success: 'success',
        info: 'info',
        warning: 'warn',
        error: 'error',
    };

    /**
     * Show an alert message
     *
     * @param {object} alert The alert parameters
     * @param {string} alert.type The alert type
     * @param {string} alert.message The alert message
     *
     * @returns {void}
     */
    self.alert = ({ type, message }) => {
        $.notify(message, {
            ...alertOptions,
            className: xTypes[type] ?? xTypes.info,
            position: "top center",
        });
    };
}));

The only feature in PHP classes is to load the Javascript files into the webpage.

The examples

A new example is introduced to illustrate the Jaxon operation.

The example now implements a simple calculator, which takes an operation and two operands as parameters, performs the calculation using an injected service, and displays the result.
There are two text zones and a select combo for the inputs, and the result is displayed in a readonly text zone.

The example is built with the new Jaxon UI components, and also released as a Jaxon package.
This package is used in the Laravel, Symfony and Slim Framework demo applications, to show how the Jaxon library can be used to build a cross-framework and full-featured package including both the frontend and backend features.

The DB Admin package and the African Tontine application are also upgraded to Jaxon 5.
Although the former is still a work in progress, both are real world examples of building complex one page Ajax applications with Jaxon.

Conclusion

The new Jaxon 5 release is packed with features that make it a good choice for creating complex Ajax applications with PHP on the server side.
There are UI components to build the webpage, custom attributes to enrich the HTML code, and powerful call factories to make calls to all kind of Javascript functions in PHP.

In addition to the documentation, there are many examples in PHP or with framework integration, and real world open source applications using the library.