cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrzej Michalec <>
Subject Re: SeachConditionBuilder for CXF JAX-RS clients
Date Tue, 08 Feb 2011 15:33:02 GMT

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
// compare with: new FiqlParser<Book>(Book.class);
SearchCondition<Book> c ="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;
way we can construct SearchCondition instantly.
Going back to text and then parse again was not a solution for me,
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
into account, after the defect
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

> 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
This is why I do like have things decomposed and human readable. You know
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:

(ok, whitespaces are not supported now, so it is an obstackle not to do this 
during cofee break :)

View this message in context:
Sent from the cxf-dev mailing list archive at

View raw message