This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » eZ Publish 5 Platform » Rendering sub-items in TWIG: is this...

Rendering sub-items in TWIG: is this a viable approach?

Rendering sub-items in TWIG: is this a viable approach?

Tuesday 17 September 2013 5:09:17 pm - 8 replies

Given the sparse examples in ezdemo, I am surely not the only one who thinks he has to invent quite a few things from scratch.

In eZ 5, even easy things as rendering a folder object in full view with its children objects in line view - certainly one of the mostly used patterns in eZ - become a challenge. I wonder how you have solved this problem, and wether my pattern is a viable approach.

I start out with a full view template. It is quite straight forward. Fetches are gone, so I have to go with a sub-request for rendering the sub-items.

In my controller there is the subItemsAction for handling the sub-items. I delegate the actual retrieval of the sub-items to a more general function which I hope to use more often.

The subItemsAction creates the response by rendering a sub_items.html.twig template. I took this extra step for being closer to the known full/line view paradigm.

Of course, this template could get much smarter, choosing line view templates according the content class to be rendered.
The line view template again is straight forward.

Of course this is only a beginning. What do you think of this approach? Do you have other ideas? Experiences? Any comment is welcome.

Modified on Tuesday 17 September 2013 5:15:31 pm by Donat Fritschy

Tuesday 17 September 2013 5:13:06 pm

Hi Donat. This is exactly the same approach i'm using. Curious to hear about another options too. 

Tuesday 17 September 2013 5:20:26 pm

Hi Carlos

thanks for your  quick reply!

I wonder what are/were the most important resources for you to learn eZ 5? Have you already completed pure eZ 5 projects?

Cheers, Donat

Tuesday 17 September 2013 5:45:51 pm

Instead of doing an include, I'd better do:

<div class="content-view-children">
    {% for location in locationList %}
        {{ render_esi( controller( 'ez_content:viewLocation' ), {'locationId':, 'viewType': 'line'} ) }}
    {% endfor %}

This will let you take advantage of template selection rules based on the line view type

Modified on Tuesday 17 September 2013 5:58:44 pm by Jérôme Vieilledent

Tuesday 17 September 2013 5:58:15 pm

Not yet Donat. And for learning, my best resources was the work done by Damien Pobel for Planet EzPublish FR, which code is available at

I found this other tutorial, very valuable too. 

Modified on Tuesday 17 September 2013 5:58:40 pm by Carlos Revillo

Wednesday 18 September 2013 10:29:56 am


I found these resources most useful too. Now, after the summer camp, a wealth of most interesting and useable information can be found at

And you confirm my impression that quite a few (but still only a few) users struggle with eZ 5, but that - except for Planet EzPublish FR - no pure eZ 5 site has gone live so far.


This is an excellent point! Thanks for mentionning.


Wednesday 18 September 2013 10:36:16 am

Regarding ESI usage, please note that the more you use ESI blocks, the less performance you will have, especially if you use the built-in reverse proxy. 

The rule of thumb is to always use a real reverse proxy (did I mention Varnish ? blunk.gif Emoticon).

Friday 04 October 2013 4:49:32 pm


but what makes sense in a full view for example to call a controller previously

Ihad in view the full $node variable that contains all the information. it was as follows: $node.children

Monday 07 October 2013 2:57:17 pm

Quote from Amine BETARI :

I had in view the full $node variable that contains all the information. it was as follows: $node.children

Hi Amine

you are right, and I wish we had the same in eZ 5 as well.

On the other hand there are always situations where you need a more elaborate subitems handling, e.g. only specific classes or a specific ordering etc. This is where subrequests come in.

Agreed, we had all in one TPL file before, now we need to combine separate controllers and templates. This looks like a big disadvantage, but it might well prove to be superior in design and performance. But for now, it's a big change for everyone.



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

36 542 Users on board!

Forums menu

Proudly Developed with from