Hi Andy
Thanks a lot for spending the time on it, very appreciated. It's a great
effort.
Comments inline.
On Sat, Mar 5, 2011 at 11:21 PM, Andrzej Michalec <
andrzej.micha...@gmail.com> wrote:
> Finally I managed to publish draft version, it's already commited as
> revision
> 1078380 (unfortunatelly Hudson/Jenkins shows previous builds failed so I
> guess the one ignited by my commit also will fail). Anyway you can find
> "org.apache.cxf.jaxrs.ext.search.client" package that has
> SearchConditionBuilder fluent interface with FIQL implementation.
> The interface is composed of subinterfaces to allow writer use only these
> operations that make sense at the moment e.g. one cannot say
> 'is("foo").and().greaterThan(10)'. This syntax checking makes writing more
> fluent for developer especially in IDE with intelli-type mechanism.
>
> Most examples are built-in unit test, but just to make a teaser, let me
> share couple examples:
>
> FiqlSearchConditionBuilder b = new FiqlSearchConditionBuilder();
>
> b.query().is("price").greaterThan(30).and().is("price").lessThan(50).build();
> // gives "price=gt=30.0;price=lt=50.0"
>
>
I'd like to have the initial query() initializer removed - it seems
redundant to me. May be I'd rename final build() with query(), just to make
things a bit different, as far as the final method in the builder pattern is
concerned :-). The builder is not meant to be used by multiple threads so
its methods such as is() can have internal checks to make sure the
initialization is done.
for complex situation with multilateral junctions, fluent interface is a bit
> broken but one can still express it like this one:
>
> PartialCondition c = b.query();
> c.is("price").lessThan(100).and().or(
> c.is("title").equalTo("The lord*"),
> c.is("author").equalTo("R.R.Tolkien")).build();
> // gives "price=lt=100.0;(title==The lord*,author==R.R.Tolkien)"
>
>
>
looks ok, we'll see further down the line what can be optimized...
> As always I am waiting for comments.
>
>
I'd also like to let people do so something like
SearchConditionBuilder.builder(). If they want to use
FiqlSearchConditionBuilder directly then it's ok, but I'd like to hide away
from them the fact they use FIQL on the client side so that the transparency
is maintained...
> The other issue I fixed is my second commit (revision 1078381) regarding
> flaw in SimpleSearchCondition. Till now it was not checked that condition
> object of type T cannot have property (getter to be precise) that returns
> primitive type. This is limiting but is necessary: mechanism heavily rely
> on
> nullability of properties - null field means it is not used as criterion;
> since primitive types are not nullable, this led to misbehavior of engine
> (which was not detected by unit tests so far). This fix introduces check
> that throws exception when detects using primitive type in property of type
> T. It means that if we want to use jaxrs-annotated POJOs they are
> additinally constrained (I had to change SearchContextImplTest to not use
> Book class from resources having getId() returning int).
>
>
I'm concerned about it.
I've seen the relevant JAXRSClientSeverBookTest being disabled and I'm
honestly not sure why
given
_s=id==2
we can not deal with Book.id being of int type ?
thanks, Sergey
cheers,
> -andy.
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3411039.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
Application Integration Division of Talend <http://www.talend.com>
http://sberyozkin.blogspot.com
