The query field type, presented during several eZ events, must be transferred to the eZ organisation and integrated within the product.

Abstract

Values of that field return, on runtime, a collection of content items based on a query that may use the current object's properties (meta and field values) as parameters.

A query field definition is configured with:

• a query type
• a content type returned by the field
• a mapping of the query type's parameters to values. The mapping is json object with the parameter's name as the key. Values can be static, or expressions (from expression language) that may use the current object's location and content.

Status

Supports field value usage from:

• PHP/Twig
• REST
• GraphQL

Possible improvements

The following is a non exhaustive collection of improvements and extra benefits from this feature. They aren't part of the story's scope.

YAML instead of JSON for parameters mapping

Cheap version: use yaml instead of json (sufficient, less prone to syntax errors).

Advanced parameters mapping UI

A dynamic form that, for each query type parameter, shows a widget allowing to select properties from the content, the location, or any of the content type's fields.

Pagination support

Support pagination for items in the various APIs.

Dynamic fields types based on query types

Instead of choosing a query type from the field definition, show a custom field type for each defined query type.

Example: two query types are defined, location children and nearby places. In the fields types dropdown, two entries are shown: "query: location children" and "query: nearby places".

Benefits:

• may allow for more semantic fields types with properly designed query types
• the dyanmic form described above is easier to implement, as the UI changes depending on the query type

Provide an abstract field type based on the mechanism above

The idea of defining new fields types based on tags, configuration, ... would be an interesting abstract mechanism to encourage and ease the creation of custom fields types.

Examples:

• an ezstring associated with a named validator: post_code, phone_number, ...
• a doctrine entity field where each enabled entity shows up as a custom field type

Advanced query types options

• hide a particular query type for the field type

More data sources

This field type returns content items based on an index (here, the search service). It can be applied to recommendation as well, and maybe to other sources.