Why a new framework?
Temma is not “new”. It has been used since 2007 on several hundred sites (including Ooreka, Skriv and Rolis).
Temma's initial goal is to get back to the basics of an MVC framework: to accelerate development by allowing developers to focus on the bulk of their work, and not having to reimplement the same thing over and over again.
Losing sight of this objective, by adding unnecessary features or by forcing the use of very strict rules, would force us to go through long learning and complicated implementation.
Temma therefore offers an environment that allows you to quickly develop your websites, offering an efficient framework, without adding unnecessary complexity.
Who is behind Temma?
Temma was developed by Amaury Bouchard, co-founder and CTO of Ooreka for 10 years, for the developments carried out internally in his company.
His goal was to set up a lightweight but fully functional framework, which facilitates the work of developers without requiring long or painful learning, and which allows to clearly separate the development work from that of HTML / CSS integration.
Where does the name Temma come from?
Initially, Temma meant "TEMplate MAnager", which clearly showed that the primary goal was to facilitate management between business code and templates. Since then, the framework has grown and offers a true MVC environment.
What is Temma's license?
Temma's source code is released under the terms of the MIT license.
You can therefore use Temma without limitation in your developments, whatever their license (free or proprietary).
Why use Temma rather than frameworks like Symfony, Laravel or Laminas?
These frameworks impose a fairly steep learning curve, forcing them to assimilate concepts that are specific to them.
You then become a Sympfony developer (for example), and no longer a “PHP developer”.
And at the same time, the simple concepts which should be handled by the framework become unnecessarily complex (try to make plugins with Symfony, you will have to develop an event listener…).
Why use Temma rather than micro-frameworks like Silex, Lumen or Slim?
These micro-frameworks may seem simpler to implement at first glance. But by mixing the routing and the controllers as they do, they make the code less readable, and therefore more difficult to maintain over time.
And for those who are based on heavy frameworks (Symfony for Silex, Laravel for Lumen), the rest of your code still suffers from the underlying heaviness.
Why is Temma using Smarty as a template engine?
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.
Why doesn't Temma generate a database administration interface?
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.
Why doesn't Temma offer an ORM?
The reasons given for using an ORM are usually:
- Don't need to write SQL queries.
- Handle only objects.
- Be able to change databases as needed.
Here's how Temma answers it:
-
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.
-
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 APIs. And yet, one could argue that data should always be manipulated in the same way, regardless of its source.
-
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.
Why do some controller attributes have an underscore at the beginning of their name, while others do not?
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.
Does Temma's dependency injection component work in the same way as other well-known frameworks?
Temma's dependency injection component operates according to a very classical schema. In itself, it is similar to other components such as PHP-DI (see Understanding Dependency Injection).
It's important to understand that Temma doesn't do auto-wiring. If we take dependency injection in its most extreme form, all objects end up having to be instantiated by the framework. Yes, all objects, even those used just once in a very rare case.
Temma's component is used more like a service locator, which has its advantages (see In Defense of Service Locator).