EXT: Project Tesseract¶

Full Recordset SDS (recordset)¶

The full recordset SDS is basically designed to return the record set resulting from a database query with added information and a (optional) recursive structure for joined tables. Obviously other sources than a database query can also return such a SDS.

An example is the best way to understand how this SDS is structured. Let's say you perform the following query using Data Query:

SELECT pages.uid, pages.title, tt_content.uid, tt_content.header FROM pages LEFT JOIN tt_content ON tt_content.pid = pages.uid

In a usual situation you would get your result in a structure like this:

List of primary keys SDS (idlist)¶

The idlist SDS is a simpler structure which is basically designed to return a list of primary keys. However these keys can be related to different tables. The structure is schematically described below:

filters¶

logicalOperator¶

limit¶

orderby¶

Custom properties may be added by extensions (e.g. the Data Query extension adds a “raw SQL” field).

Special values¶

A number of special values exist for the values found in conditions. Any implementation of the Data Filter pattern should be able to handle those values, if relevant. Special values begin with a backslash (). They are expected to be handled correctly by the Data Filter (if needed) and to be interpreted by the Data Provider. The table below lists the base special values that should be recognized and how they should be handled by the Data Provider:

Explanations¶

A Data Filter's result is passed on to a Data Provider. It is up to each Data Provider to interpret the information it receives from the Data Filter. The Data Query, for example, transforms the Data Filter information into SQL statements. So the words “table” and “field” above must be considered from a general point of view, where they might not necessarily mean a database table and a column of that database table.

The same goes for the “main condition” mentioned above. Whatever the Data Provider does, it has to interpret all the conditions of the filter. When interpreted into SQL, conditions could either go to the WHERE clause (the “main condition” in this case) or to the ON clause of the relevant JOINs. The “main” flag is an indication to the Data Provider that it should apply this particular condition to the “main condition” (e.g. the WHERE clause) if it makes such a difference at all.

Note that wherever a “table” property exists, it may be empty. It is up to the Data Provider to know what to do in such a case. For example, it should know which is the main table it is querying and assume that such a filter applies to that table.

Display Controller (displaycontroller)¶

The Display Controller is a controller that acts as FE plug-in. It thus coordinates the work of the other components to produce output that is integrated into the TYPO3 page rendering process. The Display Controller defines relationships between the various components. This is described in details in the Display Controller manual, but here's a short overview to relate this to the general schema shown above.

The Display Controller refers to one Data Consumer for the display itself. It also refers to a Data Provider that feeds the Data Consumer. This provider is called “Primary Provider”. It can also refer to a so-called “Secondary Provider” which feeds into the Primary Provider. Each provider can be linked to a Data Filter.

Advanced Display Controller (displaycontroller_advanced)¶

This controller works like a "multiple" Display Controller. It can take several groups of Data Providers and Data Filters and pass them to a single Data Consumer. It makes it possible to create sophisticated structures. Note that "templatedisplay" is not able to handle such constructs.

Data Query (dataquery)¶

Data Query is a SQL-based Data Provider. This means it relies on SQL queries to select data that is then transformed into a recordset-type SDS. Data Query hides all the handling of the TYPO3-specific fields (deleted flag and enable fields) and also transparently handles language overlays.

It can receive filtering information from a Data Filter, which is transformed into SQL syntax.

In relation with the Display Controller, it acts as a Primary Provider.

Google Query (googlequery)¶

Google Query is a Data Provider based on Google Mini or Google Search Appliance. It actually contains two providers, one returning recordset-type SDS (which acts as a Primary Provider with the Display Controller) and one returning idlist-type SDS (which acts as a Secondary Provider with the Display Controller).

Tag Pack Provider (tagpackprovider)¶

This Data Provider is based on the Tag Pack extension. It uses tags to make selections of records from various tables and returns the keys to those records in a idlist-type SDS. It can act as a Secondary Provider with the Display Controller.

The Tag Pack Provider does not interact with Data Filters.

Template-based display (templatedisplay)¶

This extension provides a way to transform the data returned by Data Providers into HTML using templates based on TYPO3's famous ### marker syntax. Thanks to a nice visual interface, it's possible to simply click on a marker and match it to a field from the list of available data. Local TypoScript processing can then be added for rendering.

Fluid-based display (fluiddisplay)¶

This extensions makes it possible to use the Fluid templating engine for rendering. This makes it possible to benefit from all the power and feature of Fluid, plus the numerous view helpers developed by the community.

PHP-based display (phpdisplay)¶

For even more flexibility, this extension makes it possible to use raw PHP for rendering. Useful in special cases where none of the above Data Consumer are enough.

Data Filter (datafilter)¶

The Data Filter extension is currently the only implementation of the Data Filter concept. It is a very flexible tool allowing to pick data from a variety of sources (in particular GET/POST variables, but also contextual values set in TypoScript or results from some common PHP functions like date()) and set it to be matched against fields used by Data Providers, so as to restrict the records that those tools return.

It also handles sorting (field and order) and limit and offset parameters.

Tesseract (tesseract)¶

This very extension is of course the basic brick of the Tesseract architecture. On top of this general documentation, it provides TYPO3 services for each of component types used by Tesseract (controller, data provider, data consumer, data filter), PHP interfaces for defining the API and some utility classes.

Improved Overlays API (overlays)¶

This extension is a tool box designed to simplify work with language overlays. On the one hand it provides very general methods which make it easy to retrieve properly overlaid records. On the other hand it also provides a number of very basic methods that handle such tasks as assembling the proper language fields conditions in a SQL statement, based on TCA definitions.

Generic Expression Parser (expressions)¶

This extension provides a library inspired by TypoScript's getText function. It makes it possible to retrieve values from a variety of sources with a simple syntax and provides a simple API for parsing strings containing such expressions. Retrieved values can also be post-processed by functions, which make it possible, for example, to quote strings tso that they are safe to use inside a SQL query.

The expression parser is at the heart of the Data Filter extension. It is also used by several other Tesseract components.

Contexts (context)¶

This extension is still in development. It aims to replace the current context mechanism found in the Display Controller.

One major aspect of Tesseract is to be able to reuse components in various places of a given web site. In particular Data Providers, which often to query the same data but with different parameters. This is possible thanks to Data Filters. Contexts take this one step further, by making it possible to define values in TypoScript which can be retrieved easily by Data Filters. This allows to have a given Data Provider be the same for a whole site and vary the content it returns just thanks to some TypoScript values that vary along the page tree.

Ideally the Contexts extension should provide a simple way to work with these values, rather than having to edit TypoScript templates.

Base component¶

All providers, filters and consumers are supposed to inherit from a base Tesseract component class ( tx\_tesseract\_component ). This class defines the following methods:

Data Provider¶

The DataProvider interface defines the methods that a data source must implement in order to be recognized as a Data Provider. These methods are:

Data Consumer¶

Similarly the DataConsumer interface defines what methods are expected from a class in order to mark it as a Data Consumer. The methods are:

Data Filters¶

The same goes again for the Data Filters, with the DataFilter interface:

Controller¶

Each controller will probably have very different logics. There are however some minimal requirements represented by two different PHP interfaces.

When setting up relationships between components a service exists to “link back” from a Consumer to a Provider. Let's take the example of the Template Display Consumer. It provides an interface for mapping fields retrieved by a related Provider to markers in a HTML template. To be able to achieve that from within the TYPO3 BE, Template Display must be “put in touch” with a Provider to which it is related via a controller. The controller service exists for that purpose.

It implements the following interface ( tx\_tesseract\_datacontroller ):

tx_displaycontroller[foo]

$this->controller->addMessage(
     'extension_key',
     'This is the debug message',
     'Title of the message (optional)',
     t3lib_FlashMessage::OK,
     array('foo', 'bar')
);