Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-30924

Integrate the query fieldtype



    • [3.0] - Sprint 21


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


      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.


      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".


      • 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.


      • 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.




            Unassigned Unassigned
            bertrand.dunogier@ibexa.co Bertrand Dunogier
            0 Vote for this issue
            2 Start watching this issue