Advanced development with eZ Find - part 3 : Leveraging the Solr syntax
Monday 05 July 2010 2:53:02 am
Step 1 : How to sort on an attribute present in several content classes
The issue
It is one of eZ Publish's timeless problematics :
- Two distinct content classes are created, for some reason : "Post" and "Article"
- Identical attributes are added to both classes, for they are useful in both, like a "Date" attribute for instance.
Result :
It is impossible to have both "Post" and "Article" objects in a fetch result, sorted by decreasing date (unless a terrifying template operator is developed for this specific purpose). Generally, developers try to use one single content class, a more generic one, to work around the issue, or rather relocate it ( mutualization of content classes has its drawbacks ).
The solution, using eZ Find
The first post in this series details the naming conventions of Solr fields. One positive side-effect of this convention (related to Solr's dynamicfields concept) is the fortunate absence of the content class identfier in the field name. This means we can leverage this homonymy as we wish, through searches, filters or sorts depending on the use-case.
eZ Publish template code example when filtering on the “Post” content class only :
{def $search_result = fetch( 'content', 'list', hash( 'parent_node_id', 2,
'class_filter_type', 'include',
'class_filter_array', array(24),
'sort_by', array( array( 'attribute', false(), 'post/date' ) ),
'limit', 10,
'depth', 3
))}Equivalent eZ Find template code example, solving our cross-content-class sort, applied to “Post” & “Article” :
{def $search=fetch( ezfind, search,
hash( query , '',
'class_id', array('post', 'article'),
'limit', 10,
'sort_by', hash('attr_date_dt', 'desc')
))}
Note :
A desirable evolution of eZ Find would be to give the possibility to use a '//date' type of syntax, in order to make optional the currently automatically added content class filter in the query sent to Solr.