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 » Location in new stack vs nodes in old

Location in new stack vs nodes in old

Location in new stack vs nodes in old

Friday 30 January 2015 4:27:42 pm - 2 replies

When fetching nodes from templates in the new stack, the attributes would be accessible from the data_map property, and could be directly rendered without any additional queries.

If I understand the new stack correctly, this is not the case when fetching Locations. If I want the actual field data, I need to make another request for the associated content (for instance, using the contentInfo of the location and the getContentFromContentInfo method of the content service) in order to be able to render the fields.

Is the decision of not making the content fields directly accessible from the location one of performance?

In most cases I'm interested in the fields when doing a location query search. Does that mean I should always to content searches instead? I'm not very clear on when a location search is correct and when a content search is preferably as they seem to somewhat overlap.

Is there somewhere where this is explained in more detail (preferrably the design decisions, and how it compares to the legacy stack)?

Friday 30 January 2015 9:10:45 pm

In general Locations in new stack is viewed at as just a (optional) list property of Content, where as in legacy stack locations where usually the center of everything.

So if you need fields you should rather use content search, Locations search is more meant to be used for lighter queries needed for generating for instance of menues and tree structures, and as soon as the translations of content name is part of ContentInfo that will be realistic for most use cases.

Modified on Friday 30 January 2015 9:11:15 pm by André R

Friday 30 January 2015 9:26:42 pm

Apart from what André says you'll probably need LocationSearch when you need queries depending on location properties like Priority maybe.

But yes, Actually my rule is going for content search if i dont need location properties involved in the query. Reason is i can save some db queries too. Actully findcontent and Findlocations return and array of results having a value object.

In findContent this is valueObject is a Content and you can easily work with twig doing things like ez_render_field( $result->ValueObject, 'field') 

But with findLocations valueObject is a Location and you will need an additional query (vía ContentService more Sure) to load the entire content.

That said if i'm not wrong happy.gif Emoticon


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

36 542 Users on board!

Forums menu

Proudly Developed with from