cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrzej Michalec <andrzej.micha...@gmail.com>
Subject Re: SeachConditionBuilder for CXF JAX-RS clients
Date Tue, 08 Feb 2011 19:57:11 GMT

> is("title").equalTo("The Lord") is a strict match.
> is("title").matching("The Lord") is a partial match.
> Hope we are on the same page :-)

yeap, we can do that

> It only needs to produce a *raw query text* for the consumption of the
> client code building a request URI.

Click! It seems my CPU was overheated so I missed that critical goal, now I
"got that" :) 
You are absolutely right. The only excuse I can hide behind is "name
snapping". SearchConditionBuilder was too close to SearchCondition working
on server site; now I see now we are about to make FiqlBuilder ;) that makes
FIQL statementm, which on server side is decomposed by FiqlParser. Thanx to
lack of time I have only prototyped interfaces and did not waste time on
unnecessary impl.

> The builder should help producing "name=foo* and
> (name!=*bar or level>10)".
> Thus we will let users to type a search-language portable code because
> another builder instance will produce
> an XQuery/XPath expression, using the same sequence of builder calls 

Right. Being pedantic to the very end, I think we should give a right name
for the builder to (a) abstract out of implementation (e.g. not only
FiqlBuilder for interface name) and (b) somehow distinguish client-side from
server side (e.g. we are using SearchCondition for server-side and
SearchConditionBuilder does not suggest it works on client side). Maybe we
should introduce subpackages for client/server. I will take a look and get
back with some propositions.

cheers,
-andy.
-- 
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3376520.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Mime
View raw message