I could not reply earlier, Sergey knows I am (still) attending to my
company's internal event ;)
Just couple first thoughts on the subject.
The FIQL that we suport is quite simple and basically is about comparing
properties of given entity with constant values and then combine these
simple boolean results with conjuntions/disjunctions. From fluent interface
perspective simple expression could be like this:
SeachConditionBuilder.query(new Book()).is("title").matching("The
Lord*").build();
SeachConditionBuilder.query(new Book()).is("price").lessThan(20).build();
SeachConditionBuilder.query(new Book()).is("issueDate").before(new
Date(...)).build();
where query() method is factory producing builder instance, is() is property
resolver, plus rightmost set of comparators.
Of course naming of methods is a question of further tuning.
For same level junctions and()/or() methods can be mixed in a flux of
sentence like this:
SeachConditionBuilder.query(new
Book()).is("price").lessThan(20).and().is("issueDate").before(new
Date(...)).build();
For multiple junctions we need to apply default precedence (first ANDs then
ORs) and we can do this similar way as in parser; it increases a bit
complexity of builder but can be done pretty easy.
In case of non default precedence, like "(A or B or C) and D" we need notion
of parenthesis. I have seen similar discussion on nesting expressions in
flunece interfaces
(see
http://groups.google.com/group/morphia/browse_thread/thread/61d1a05ec5d0de6b?pli=1).
I would avoid in-flow parenthesis like this:
query(...).openParen()...or()...closeParen().and()...
and break flow of expressions into sections like this:
Criteria c = SeachConditionBuilder.query(new Book());
c.and(
c.is("price").lessThan(20).or().is("price").greaterThan(50),
c.is("issueDate").before(new Date(...))
).build();
or equivalent:
c.and(
c.or(
c.is("price").lessThan(20),
c.is("price").greaterThan(50) ),
c.is("issueDate").before(new Date(...))
).build();
As you can see in opposite to Sergey's proposition on
single-string-comparisons (i.e. "price < 20") I vote for fine-grained
decomposition... if we want to have these kind of stringified expressions I
guess we should go into full user-friendly parser to handle above complex
expression as it goes: "(price<20 or price>50) and issueDate<2010-01..."
all comments are welcome
cheers,
-andy.
--
View this message in context:
http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3369018.html
Sent from the cxf-dev mailing list archive at Nabble.com.
