Details
-
Improvement
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Platform Sprint 140
Description
I explained it in the javadoc:
org.hippoecm.hst.content.beans.query.builder.ConstraintBuilder public static ConstraintBuilder constraint(String fieldName) The fieldName is in general a property name, for example example:title. Depending on the filter method (equalTo, notEqualTo, contains, etc) the fieldName is limited to certain conditions. For all ConstraintBuilder constraints methods the fieldName is allowed to be of the form myhippo:title or address/myhippo:street where the latter is a constraint on a child node its property. There is one exception: When you use like(String) or notLike(String), it is not allowed to do the constrain on a child node property. For the constraint contains(String) and notContains(String) the fieldName can next to myhippo:title or address/myhippo:street also be equal to "." meaning a text constraint on node scope (instead of property) level is done When you do not invoke a explicit ConstraintBuilder method, for example equalTo(Object), but just use something like constraint("myproject:title") in the HstQueryBuilder.where(ConstraintBuilder), the ConstraintBuilder falls back to a property must exist constraint, thus exists(). If you do invoke an explicit ConstraintBuilder method, for example equalTo(Object), but the argument is null, the effect is that this ConstraintBuilder in HstQueryBuilder.where(ConstraintBuilder) is ignored. This way, when using the fluent api, you can skip null checks. For example .where( constraint(".").contains(query) ) will result in the constraint to be skipped if the query turns out to be null. Parameters: fieldName - the fieldName this filter operates on, not allowed to be null Returns: a new FilterBuilder for fieldName
I think for ease of use of the fluent api, it is nice to be able to skip null checks