On Oct 7, 2014, at 7:41 PM, Aristedes Maniatis <[email protected]> wrote:
>> Yes both are valid. The point of the new one is that deeply nested >> expressions can not be easily built within a context of query, so you'd >> build them separately and then pass the final object to the query. So >> query.or/and(..) is sort of a final step in the qualifier assembly. >> ExpressionFactory.or/and(..) is to build the clauses you pass in there. > > > Fair enough. Then we'll keep both approaches as valid and possible? Yes. > I'd suggest the second syntax is the one we'd want to push as the > introductory approach in the tutorials however... it is simple and easier to > understand without the static imports. When the expression is at most 2 levels deep, I agree. Since all of our tutorials are like that, we'll use query.and/or. > Personally I don't see the pattern with static imports as something I'd use, > but perhaps other people would. Between Property API (as John has mentioned) and query.and/or, ExpressionFactory itself becomes somewhat irrelevant to the end user. Once we commit that pull request and I have a chance to switch my big projects to it, I am curious myself of how many places would actually make use ExpressionFactory. "db:" expressions are still a use case. Also - will need to change query.and/or into a vararg. Overlooked it on the first path. Andrus
