I am back again.
> nice, may be even matching("The Lord") because 'matching' probably means a
> partial match, we can also have equalTo, similar to lessThan/etc.
Today equal operator (in FIQL world) is capable of handling literal
equality and pattern matching. I just forgot about that and this is
why I said 'matching'. It should be just 'equalTo'.
If 'is("title").equalTo("The Lord*")' as pattern is couterintutive, we can
introduce 'matching' that adds asteris at the
beginning and at the end. Now I would stick with equalTo() referring
one-to-one to '=eq=' operator.
> I see. I'm not sure though about using Book.class to get a builder. The
> builder is really a little helper which can let users convert a captured
> query state into the FIQL/etc language...In other words,
>
> SeachConditionBuilder.newInstance().is("price").lessThan(20).build();
>
> can easily generate 'price=lt=20' without knowing about Book.class :-).
FiqlParser to produce generic-aware SearchCondition<T> takes Class<T> as
parameter to be able to construct instances used for comparison (this is
how SearchConditoin works). By mistake I put 'query(new Book())' while
I should have use Book.class. At the moment my prototype does something
like this:
SearchConditionBuilder<Book> b = new
SearchConditionBuilder<Book>(Book.class);
// compare with: new FiqlParser<Book>(Book.class);
SearchCondition<Book> c = b.is("title").equalsTo("foobar").build();
> can easily generate 'price=lt=20' without knowing about Book.class :-).
This is interesting. I did not think about builder generating text for
parser --
this is because fluent methods chain gives us syntax tree nearly for free;
that
way we can construct SearchCondition instantly.
Going back to text and then parse again was not a solution for me,
especially
because FIQL will never get more complicated, that is intent of authors,
and for me this would only rationalize going through parser again - to keep
grammar checking in one place. I am particularily cautious, and take
performance
into account, after the defect
https://issues.apache.org/jira/browse/CXF-3262
considering flag return instead of exception. :)
What do you think?
> I also propose making and() optional, if that is feasible
I decided to make fluent builder using multiple interfaces. This tricky way
some "words" are available only in particular moments, and user is "guided"
using intelli-type mechanism, what can be "said" at the moment.
This way at the moment and/or is required to make the flow of typing "the
sentence". Let's have this topic reviewed when the first code draft is
available.
> So I was thinking that the user just gets the "a > b" literal value
> [...]
> May be we can consider supporting both types of building ? But really like
> the things like is() + matching(), before(), etc. I guess the only concern
> is that I'd use Book()/etc instances as shortcuts as opposed to factory
> methods :-)
My feeling is that fluent builder is for authors/coders, not for
machine/automatons.
This is why I do like have things decomposed and human readable. You know
what?
Building FIQL parser I was thinking that it would be good idea to have also
user-friendly FIQL grammar with second set of tokens (e.g. with "=",">"...
for "=eq=","=gt=" and so on). It is still quite easy to do so we can make up
the full-blown parser that can consume:
"name=foo* and (name!=*bar or level>10)"
same way as FiqlParser consumes today this:
"name==foo*;(name!=*bar,level=gt=10)"
(ok, whitespaces are not supported now, so it is an obstackle not to do this
during cofee break :)
cheers,
-andy.
--
View this message in context:
http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3376071.html
Sent from the cxf-dev mailing list archive at Nabble.com.
