eZ Community » Forums » Discussions » Call for developer feedback: the...

Friday 14 March 2014 1:06:22 pm - 10 replies

» Read full blog post


We believe that even though only bad craftsmen blame their tools, one still does a better job with the right one. A sledgehammer will get a standard nail into a plank, but it will take more preparation, more care and more time than with a good old hammer.

Now that the foundations of our repository and its API are established, we want to take a step up another layer, and focus on developer usability by making it easier to query the repository for content. But we lack the one thing you can provide us with: feedback and use-cases. But let’s explain what the situation is, and what we have in mind exactly.

Friday 14 March 2014 4:09:55 pm

Thank you so much Bertrand for taking care of us.

Here are my requests:

  • I want to retrieve all the contentType written by an user
  • I want to retrieve all articles with a rating between 4 and 5 stars (ezstarrating)

Friday 14 March 2014 4:12:31 pm

For some background info of this blog post, check out the following:

Original forum thread with proposals from Eirik Alfstad Johansen and Joe Kepley:

Feature request JIRA issue:


Followup feature request to make this available in twig templates so you can reuse a out of the box content list and tree view to avoid having to create your own controller for normal querying needs:


The missing part right now for your last use case are criterion and sort clause for Star Rating, we added these for MapLocation recently which serves as an good example for how Rating functionality can be made and contributed if someone are up for it.

Modified on Friday 14 March 2014 4:17:49 pm by André R

Friday 14 March 2014 4:19:00 pm

Note that I started drafting what field() filtering/sorting could look like, depending on what we can actually do. It's probably the most complex part of the whole builder idea, at least if we want it right contextually speaking...

Saturday 15 March 2014 2:43:43 pm

Hi all!

I like the approach stated in the article, fields filtering/sorting is for sure one of the trickiest and most important part IMHO

Thanks for your work, Gabriele

Saturday 15 March 2014 2:50:35 pm

In regards to what Sylvain mentioned, and filtering sorting on "advanced' data (understand "fields"blunk.gif Emoticon, more semantic criteria are clearly needed, like was done for the MapLocation.

I'm trying to think of a proper API for that, and may have something suitable in mind.

Monday 17 March 2014 10:36:10 am

I'm unsure if a "real fluent API" will make things a lot easier. The examples you show are simple compared to the filters we sometimes have to develop in client projects.

So let's assume we have an example with logical ANDs combined with ORs plus brackets to control the order of execution, I can see following downsides:

  • It's going to be a lot of typing. IDEs with autocomplete are helping but let's be honest it's working only OKish in PHP (compared to java), it's not like it can guess what you need - you still need to know in what namespaces the classes are, or what the classes are called
  • because it's a long code string, I think it's NOT going to be very simple to read and understand a query filter in the proposed syntax
  • knowing it could be easier, it's not a lot of fun spending so much time writing the query filters
  • the syntax only works in PHP

It would be soo cool if we could use something similar to the solr query syntax. Most ezp developers probably have some experience with it. Personally, I really enjoy it, because I can write a complex filter that result in a long string but it's still quite compact and easy to read and understand. Because it's a simple string, I could build a query filter in context of PHP, template language and javascript. That's so much better than having 3 different approaches in those 3 languages.

Also, if you're unsure about the best approach, you could consider to implement a query parser that developers can override in order to allow different syntaxes (approaches) to build the query.

Modified on Monday 17 March 2014 11:35:08 am by Philipp Kamps

Monday 17 March 2014 11:12:20 am

Having used the query builder for a few months now, I have to say I quite like it. Sure my code is verbose, but it's also super clear. This can be really helpful when working with a large team of developers.

Here is my feature request:



When I do a fetch for:

 Criterion\ContentTypeIdentifier( array( 'article', 'folder' ) )


It would be nice to have the option to get the results as a tree. Andre hinted that this might be easier with the changes in 5.3.

Thursday 20 March 2014 2:54:16 pm

A few more things to consider:

  • Bertrand's approach should actually work quite well with IDE autocomplete. Because you're always in context of an PHP instance and the autocomplete suggests context relevant methods. So I think in that perspective it is an improvement to the existing query builder
  • We often need to dynamically build queries. Maybe the advanced search in ezp is a good example: The user only specifies a few of the search options. In PHP we'd dynamically add those search options to a query builder. I'm not sure how I would do that in Bertrand's approach
  • A bit off-topic: We built an interface in the admin UI to construct eZ Find filters. The UI also shows us the result set. It allows us to verify that the filter is indeed showing us what we expect. So sometimes it makes sense to develop a query NOT in your IDE but in a tool that also shows you the result set.

Thursday 20 March 2014 4:49:37 pm

Great feedback everyone, keep it coming!

Friday 21 March 2014 4:01:30 pm

Quote from Philipp Kamps :
  • A bit off-topic: We built an interface in the admin UI to construct eZ Find filters. The UI also shows us the result set. It allows us to verify that the filter is indeed showing us what we expect. So sometimes it makes sense to develop a query NOT in your IDE but in a tool that also shows you the result set.

We definitely have this in mind as well, long story short we want to:

  • Make the "view" feature of REST v2 support all valid content / location queries
  • Persist it by creating API and storage of this
  • In future create UI to allow editors to easily create these
    • We might also consider making a text version ala Doctrine Query Language and JIRA Query Language
  • Natively use these for all places list of content / locations are natural, for instance ezflow block for list of content
  • Also allow using these from templates for pre defined queries

Modified on Friday 21 March 2014 4:04:13 pm by André R


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from