Frequently Asked Questions

Temma is used in production by companies whose servers cannot always keep up with the pace of PHP version releases.

As a result, we have chosen to remain compatible with the version of PHP provided in the second-to-latest Long-Term Support (LTS) release of the Ubuntu Linux distribution.

Temma’s dependency injection component follows a very classical design. In essence, it is similar to other components such as PHP-DI (see Understanding Dependency Injection), except that it integrates the handling of specific cases that are unique to Temma.

Temma’s component can be used either as a service locator or through autowiring. The typical usage is to rely on the service locator in controllers and to use autowiring for business objects.
It is, however, possible to use the service locator throughout all objects in an application, which comes with certain advantages (see In Defense of the Service Locator), at the cost of tighter coupling in the code.

The reasons given for using an ORM are usually:

1. Don't need to write SQL queries.
2. Handle only objects.
3. Be able to change databases as needed.

Here's how Temma answers it:

1. For queries on a single table, Temma's DAOs do not require writing SQL queries. For more complex queries (joins, groupings, ...), it is always more efficient to write the queries "by hand".

   To overcome their performance problems, ORMs offer languages derived from SQL (HQL for Hibernate, DQL for Doctrine). Developers should always write their requests, except that they are handled by an intermediate layer (with its specific syntax and associated slowness).

   Whatever developments have been made, it will be necessary to check the database to see if everything is stored correctly. And therefore, it will be necessary to type SQL queries. A web developer who is not able to do this will quickly have problems.

2. If the desire to only manipulate objects can be understood in certain environments, the "PHP way of life" is very well suited to data transfer based on simple lists and associative arrays. It is the most flexible and fast way to architect your developments in PHP.

   In fact, even developers who only want to manipulate "entities" (the objects representing data in the database) use associative arrays when connecting to exernal APIs. And yet, one could argue that data should always be manipulated in the same way, regardless of its source.

3. The real layer of abstraction is the DAOs. The business code that calls for it does not have to be modified, even in the event of profound modifications which require changing the requests present in the DAOs.

Rather than using an existing ORM as Doctrine or relying on the Active Record pattern, Temma uses the Data Access Object (DAO for short) pattern. This is both more efficient in its execution and easier to use.

The use of DAO is crystal clear:

• To retrieve data from a record in a table, we call a DAO method. We get an associative array, which proposes a key for each field in the table.
• When we retrieve several records from a table, we get a list of associative arrays. You can iterate over it with all native PHP functions like foreach. It's simple, clear, effective.
• By avoiding converting each result row of a query into an object, we avoid unnecessary memory consumption and additional processing.

Smarty is the de facto standard for PHP template engines.

It has several qualities:

• A simple and clear syntax, easily assimilated by graphic designers far from the logic of development.
• Extension possibilities easy to implement, with the creation of filters in PHP.
• Performance that can be adjusted by adding cache on template fragments.

Even if the criticism of Smarty seems to be hype from some active “thinkers” in the PHP community (mainly those who end up proposing clones of Smarty), its wide adoption by a silent majority of this same community cannot be questioned.

Because it will be more efficient to use PhpMyAdmin, PhpPgAdmin, PhpRedisAdmin, Adminer…

It is not the role of a framework to offer this kind of functionality. The role of a framework is to provide the technical bases that allow these tools to be developed.

The attributes which have an underscore at the beginning of their name are automatically created by Temma:

• $this->_session is created by the framework, unless the configuration explicitly disables sessions.
• $this->_loader is always created by the framework, to handle dependency injection.

In contrast to this, the data source access attributes have the same name as what was defined in the dataSources section of the configuration (see the documentation).

These names depend entirely on your configuration. For example, the connection to the database might be called different from "db" (you can choose "database", "sql", "mysqlserver3", or whatever).
However, note that the cache plugin expects the connection to the cache to be called "cache" and nothing else.

In most PHP frameworks, attributes are passive: they describe an intention, but it is the framework core that scans them and applies the corresponding logic.

Temma deliberately made a different choice: attributes are active objects.
When they are instantiated, they can directly use the framework API (HTTP response, view, security, execution flow, etc.) to modify the application’s behavior.

The framework does not need to know all possible attributes in advance: it provides an execution context, and the attributes themselves apply their logic.

This model allows developers to:

• create their own functional attributes;
• extend application behavior without modifying the framework core;
• build simple, local, and readable plugins.

An attribute that is not instantiated by Temma remains completely inert, so there are no hidden side effects.

Temma’s loader (dependency injection component) follows an aspect-oriented programming approach, more specifically aspect-oriented dependency injection: attributes act as application aspects, applied at well-defined points in the execution cycle.