You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andrzej Michalec <an...@gmail.com> on 2011/02/03 10:31:21 UTC
Re: SeachConditionBuilder for CXF JAX-RS clients
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.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 07 March 2011 7:30:32 AM Andrzej Michalec wrote:
> Another hint for environment. Being seasonal contributor I faced problems
> with JDK1.5 build. I did not spot problems since I am using JDK1.6 locally
> and generated Eclipse workspace did not force me to use compatibility with
> 1.5. Maybe maven should generate by default code compatibility 1.5 instead
> of latest-greatest; this way we would reduce problems injected by
> contributors regenerating workspace.
I'm all for that, if you can figure out how to do it. :-) I did spend a
little time on it a while ago but couldn't figure out the magic incantations
to get it all working without doing some major duplication of various profiles
in the poms. :-(
Seriously, if you run the setup.eclipse with something like:
mvn -Psetup.eclipse -Dcxf.jdk.version=1.5
it will set the eclipse projects to 1.5 level. HOWEVER, since we don't
include some of the dependencies that are built into the JDK when building
with Java6, the projects won't work in eclipse as things like JAXB and stax
and such won't be there. You MAY be able to do:
mvn -Psetup.eclipse,jdk15 -Dcxf.jdk.version=1.5
as that would bring in the 1.5 deps. However, that would also then generate
JAXWS 2.2 and JAXB 2.2 code. I'm not sure if that would then work in the
restricted "1.5" environment or not. You could give it a try.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
Thanks a million - I do hope this builder will help users to experiment with
FIQL.
Cheers, Sergey
On Tue, Mar 15, 2011 at 3:35 PM, Andrzej Michalec <
andrzej.michalec@gmail.com> wrote:
> Refactoring is done, SearchConditionBuilder is factory now, removed
> unnecessary "query" operation, plus renamed "build" into "query".
>
> cheers,
> -andy.
>
>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
Refactoring is done, SearchConditionBuilder is factory now, removed
unnecessary "query" operation, plus renamed "build" into "query".
cheers,
-andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3707706.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Removing Nabble links...
On Wed, Mar 9, 2011 at 10:40 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Andy
>
> On Tue, Mar 8, 2011 at 9:58 PM, Andrzej Michalec <
> andrzej.michalec@gmail.com> wrote:
>
>> > sorry, I'm not following :-) We have PrimitiveSearchCondition which
>> wraps
>> an
>> > expression like "a==2".
>> > [...]
>>
>> I spent an hour trying to recreate that problem and actually I confused
>> myself because I am not able to do so :) When I started working on search
>> condition builder I did a little play with FiqlParser and
>> SimpleSearchCondition and found problems I described. I was sure I did
>> update to head revision. Anyway, then I trashed these files as irrelevant
>> to
>> our fluent interface case, but I remembered in back of my head troubles I
>> reached and tested. Now I have neither idea nor time to figure that out
>> especially that it is really working! I think it is your refactoring to
>> PrimitiveSearchCondition that get rid of problem I faced. Well... feeling
>> shamed a bit I am happy at the same time that the code is really stable.
>>
>>
> Not a problem at all and the really good thing is that you've looked again
> through the code you wrote awhile back and thus enhancing it can be a walk
> in the park for you in the future :-). Thanks for taking care of this issue
> - you may've spotted something after all and if yes then the issue will be
> back on the agenda soon :-)
>
>
>> I am going to revert these changes in minutes and then tune up
>> SearchConditionBuilder as we agreed.
>>
>> cool, thanks
>
> Sergey
>
>
>> cheers,
>> -andy.
>>
>>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
> sorry, I'm not following :-) We have PrimitiveSearchCondition which wraps
an
> expression like "a==2".
> [...]
I spent an hour trying to recreate that problem and actually I confused
myself because I am not able to do so :) When I started working on search
condition builder I did a little play with FiqlParser and
SimpleSearchCondition and found problems I described. I was sure I did
update to head revision. Anyway, then I trashed these files as irrelevant to
our fluent interface case, but I remembered in back of my head troubles I
reached and tested. Now I have neither idea nor time to figure that out
especially that it is really working! I think it is your refactoring to
PrimitiveSearchCondition that get rid of problem I faced. Well... feeling
shamed a bit I am happy at the same time that the code is really stable.
I am going to revert these changes in minutes and then tune up
SearchConditionBuilder as we agreed.
cheers,
-andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3414726.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
>
> Regarding SimpleSearchCriteria flaw it is rooted in
> SearchCriteria.getCondtition() interface operation that I think must be
> removed from the contract. It suggests possibility of using type T as
> condition data holder which was actually done in SimpleSearchCriteria. And
> this led us to limitation with primitives properties which is the reason of
> our problem now. Anyway, the rework has begun ;)
>
>
sorry, I'm not following :-) We have PrimitiveSearchCondition which wraps an
expression like "a==2". The actual condition instance is say Book. Having
getCondition() returning Book is not ideal in this case but
PrimitiveSearchCondition also has getters identifying a particular property
this PrimitiveSearchCondition is centered around.
What is the code which is passed SearchCondition wants to do the match
differently by traversing SearchCondition for the sub-conditions and using
the actual condition instance to make the match against the data which can
not be easily assembled into say List<Book> for SearchCondition.findAll() to
work ?
> Another hint for environment. Being seasonal contributor I faced problems
> with JDK1.5 build. I did not spot problems since I am using JDK1.6 locally
> and generated Eclipse workspace did not force me to use compatibility with
> 1.5. Maybe maven should generate by default code compatibility 1.5 instead
> of latest-greatest; this way we would reduce problems injected by
> contributors regenerating workspace.
>
>
+1
cheers, Sergey
> cheers,
> -andy.
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3412343.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
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
>> May be we can make SearchConditionBuilder an abstract class? Have an
>> > internal FiqlSearchConditionBuilder as the default instance ...
>>
>> Yeap, you have just verbalized what I wanted to do.
>
> Sorry about it Andy, can't help it, not a great habit :-)
Quite opposite, it is good habit, it decreases misunderstanding; it was just
my confirmation we are on the same page.
Regarding SimpleSearchCriteria flaw it is rooted in
SearchCriteria.getCondtition() interface operation that I think must be
removed from the contract. It suggests possibility of using type T as
condition data holder which was actually done in SimpleSearchCriteria. And
this led us to limitation with primitives properties which is the reason of
our problem now. Anyway, the rework has begun ;)
Another hint for environment. Being seasonal contributor I faced problems
with JDK1.5 build. I did not spot problems since I am using JDK1.6 locally
and generated Eclipse workspace did not force me to use compatibility with
1.5. Maybe maven should generate by default code compatibility 1.5 instead
of latest-greatest; this way we would reduce problems injected by
contributors regenerating workspace.
cheers,
-andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3412343.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Missed the actual link:
http://en.wikipedia.org/wiki/ISO_8601
Sergey
On Sun, Mar 13, 2011 at 1:15 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Andy
>
> On Fri, Mar 11, 2011 at 8:24 PM, Andrzej Michalec <
> andrzej.michalec@gmail.com> wrote:
>
>> > Just FYI, I'm updating FiqlParser for the date format be configurable
>> (via
>> > context properties) because we can expect dates in all sort of formats,
>>
>> Sergey, FIQL RFC draft explicitly states the only date format which is XML
>> Schema dateTime
>> (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime).
>
>
> Sorry, I actually missed that fact.
>
>
>> Nevertheless
>> I am ok with such relaxation and customized date formats as long as we
>> keep
>> defaults as in spec.
>>
>>
> Sounds good, I did a simple update where the defaults are the ones you were
> using originally.
> I think I can add some code later on to do the validation. I've looked at
> [1] and it seems ISO-8601 is lax enough about the possible variations. My
> motivation was to make it simpler to use date-based queries, example, I have
> a test with two log files, created and closed at different dates, say
> 2011-01-22 and 2011-01-23. So having 'date=lt=2011-01-23' is a simple way to
> check all the records before 2011-01-23. But I agree - we'll need to enforce
> it...
>
>
>
>> > Hope it won't interfere with your refactoring (the hiding of query()),
>>
>> I am fine, I am going to do that this weekend, so I will update to head
>> and
>> move on.
>>
>> I left query() unchanged, only added another constructor and then the
> optional properties are passed to PartialConditions and also made visible to
> children...
>
> thanks, Sergey
>
> cheers,
>> -andy.
>>
>>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
On Fri, Mar 11, 2011 at 8:24 PM, Andrzej Michalec <
andrzej.michalec@gmail.com> wrote:
> > Just FYI, I'm updating FiqlParser for the date format be configurable
> (via
> > context properties) because we can expect dates in all sort of formats,
>
> Sergey, FIQL RFC draft explicitly states the only date format which is XML
> Schema dateTime
> (http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime).
Sorry, I actually missed that fact.
> Nevertheless
> I am ok with such relaxation and customized date formats as long as we keep
> defaults as in spec.
>
>
Sounds good, I did a simple update where the defaults are the ones you were
using originally.
I think I can add some code later on to do the validation. I've looked at
[1] and it seems ISO-8601 is lax enough about the possible variations. My
motivation was to make it simpler to use date-based queries, example, I have
a test with two log files, created and closed at different dates, say
2011-01-22 and 2011-01-23. So having 'date=lt=2011-01-23' is a simple way to
check all the records before 2011-01-23. But I agree - we'll need to enforce
it...
> > Hope it won't interfere with your refactoring (the hiding of query()),
>
> I am fine, I am going to do that this weekend, so I will update to head and
> move on.
>
> I left query() unchanged, only added another constructor and then the
optional properties are passed to PartialConditions and also made visible to
children...
thanks, Sergey
cheers,
> -andy.
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3425716.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
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
> Just FYI, I'm updating FiqlParser for the date format be configurable (via
> context properties) because we can expect dates in all sort of formats,
Sergey, FIQL RFC draft explicitly states the only date format which is XML
Schema dateTime
(http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime). Nevertheless
I am ok with such relaxation and customized date formats as long as we keep
defaults as in spec.
> Hope it won't interfere with your refactoring (the hiding of query()),
I am fine, I am going to do that this weekend, so I will update to head and
move on.
cheers,
-andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3425716.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
>
> > May be we can make SearchConditionBuilder an abstract class? Have an
>> > internal FiqlSearchConditionBuilder as the default instance ...
>>
>> Yeap, you have just verbalized what I wanted to do.
>>
>
Just FYI, I'm updating FiqlParser for the date format be configurable (via
context properties) because we can expect dates in all sort of formats,
example, we probably won't be asking users to provide a time zone in the log
browser, etc...
And I added the similar config to the FiqlSearchConditionParser, which now
has two query methods:
query()
query(Map<String, String> properties)
Hope it won't interfere with your refactoring (the hiding of query()),
SearchConditionBuilder can have factory methods with no args, the map
properties arg only as well.
thanks, Sergey
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
>
> On Mon, Mar 7, 2011 at 11:52 AM, Andrzej Michalec <
> andrzej.michalec@gmail.com> wrote:
>
>> > Actually, I added a test to the JAXRSAtomPushLoggingSpringTest which
>> > searches the log records using the queries like
>> 'level==INFO,level==WARN'.
>> > And for that to work I had to make the change to FIQLParser to ensure
>> that
>> > SimpleSearchCondition was only initialized with the map of properties
>> > which
>> > were specified in the query given that LogRecord has the dozen (or so
>> :-))
>> > of other properties. Thus I'm not sure why to fail the match if the
>> > property, even it is primitive, is not even checked ?
>> ...
>> > Are you saying you are ok with reverting the change ? If yes then +1.
>>
>> Sergey, all I am saying is I need to change the implementation a bit.
>> After
>> that I will revert/re-enable tests to have everything working as it should
>> be.
>>
>>
> Super :-).
>
One thing I forgot to mention. SearchCondition lets people register custom
visitors and SQLPrinterVisitor is provided OTB. So users do not delegate
back to SearchCondition to filter out the beans which do not match. Instead
they just use SearchContext/SearchCondition as a tool for converting FIQL
expressions into SQL/etc specific expressions.
However given that SearchContext/SearchCondition are parameterized by
concrete types such as Book, the query 'space' is limited by properties of
Book (and possibly, in the future) by properties of its internal beans.
Which is probably fine for most applications but to have the FIQL-to-SQL
case working without restrictions so that people could just query the
arbitrary dbs I'm planning to introduce some map-like class which would be
handled by the parser with some exceptions. I'm not going to do it for 2.4.0
but just letting you know - comments are welcome
Sergey
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
On Mon, Mar 7, 2011 at 11:52 AM, Andrzej Michalec <
andrzej.michalec@gmail.com> wrote:
> > Actually, I added a test to the JAXRSAtomPushLoggingSpringTest which
> > searches the log records using the queries like
> 'level==INFO,level==WARN'.
> > And for that to work I had to make the change to FIQLParser to ensure
> that
> > SimpleSearchCondition was only initialized with the map of properties
> > which
> > were specified in the query given that LogRecord has the dozen (or so
> :-))
> > of other properties. Thus I'm not sure why to fail the match if the
> > property, even it is primitive, is not even checked ?
> ...
> > Are you saying you are ok with reverting the change ? If yes then +1.
>
> Sergey, all I am saying is I need to change the implementation a bit. After
> that I will revert/re-enable tests to have everything working as it should
> be.
>
>
Super :-).
> > SearchConditionBuilder will be part of the 2.4 release so it will be a
> new
> > feature, or may be rather the enhancement toward making the search
> feature
> > more complete as it will facilitate using FIQL on the client side...
>
> Agreed. I just asked when it is planned. Despite the date I will make this
> fix ASAP ;)
>
>
ok, and please let me know if any help is needed. I think we have at least 2
weeks.
While we will talk about it as the new feature/enhancement, I think we can
definitely afford not to freeze the interface(s) for a bit. It would be
great if say between 2.4.0 and 2.4.1/2 maintenance releases we could get
some feedback from the early adopters, it's very hard at this stage to come
up with the perfect solution. Example, I think this interface will be of
great use for people writing tests and the specific code where the number of
options is limited and/or known in advance. I'd like to understand better
and may be try to do some demo where custom HTML forms are introduced
letting users do arbitrary queries and then see if some relevant changes are
needed...
> May be we can make SearchConditionBuilder an abstract class? Have an
> > internal FiqlSearchConditionBuilder as the default instance ...
>
> Yeap, you have just verbalized what I wanted to do.
>
> Sorry about it Andy, can't help it, not a great habit :-)
thanks, Sergey
> cheers,
> -andy.
>
> PS. what do you think about Robert's suggestion on usecases map? Shall we
> have separate thread on this?
>
> Having the usecases map is a good idea. We can definitely add few entries
to that map :-)
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
> Actually, I added a test to the JAXRSAtomPushLoggingSpringTest which
> searches the log records using the queries like 'level==INFO,level==WARN'.
> And for that to work I had to make the change to FIQLParser to ensure that
> SimpleSearchCondition was only initialized with the map of properties
> which
> were specified in the query given that LogRecord has the dozen (or so :-))
> of other properties. Thus I'm not sure why to fail the match if the
> property, even it is primitive, is not even checked ?
...
> Are you saying you are ok with reverting the change ? If yes then +1.
Sergey, all I am saying is I need to change the implementation a bit. After
that I will revert/re-enable tests to have everything working as it should
be.
> SearchConditionBuilder will be part of the 2.4 release so it will be a new
> feature, or may be rather the enhancement toward making the search feature
> more complete as it will facilitate using FIQL on the client side...
Agreed. I just asked when it is planned. Despite the date I will make this
fix ASAP ;)
> May be we can make SearchConditionBuilder an abstract class? Have an
> internal FiqlSearchConditionBuilder as the default instance ...
Yeap, you have just verbalized what I wanted to do.
cheers,
-andy.
PS. what do you think about Robert's suggestion on usecases map? Shall we
have separate thread on this?
--
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3412308.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Sorry for the possible noise, seems like the message is being rejected if it
contains Nabble links...
On Mon, Mar 7, 2011 at 10:33 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Andy
>
> On Sun, Mar 6, 2011 at 9:36 PM, Andrzej Michalec <
> andrzej.michalec@gmail.com> wrote:
>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > I'm concerned about it.
>> > I've seen the relevant JAXRSClientSeverBookTest being disabled and I'm
>> > honestly not sure why
>> > given
>> > _s=id==2
>> >
>>
>> You could use this query on "id==2" and it worked (you have made
>> unit/system
>> tests). The trick is that when one would make up a query with "name==CXF*"
>> only, without id, this certailny fails since id is internally set to zero
>> instead of null
>
>
> If we start enforcing it then I'm concerned it would make the search
> extension limited.
> The match should be attempted at the individual property level only, that
> is in your example, only a 'name' property should be compared, or
> SimpleSearchCondition should only be initialized with a single internal
> condition only.
>
> I'm not sure at all if we can expect 'real' beans containing non-primitive
> properties only and thus we probably can be 'assured' people won't be using
> SearchCondition.findAll/isMet if for that to work they have to change them
> to meet the new restriction...
>
> Actually, I added a test to the JAXRSAtomPushLoggingSpringTest which
> searches the log records using the queries like 'level==INFO,level==WARN'.
> And for that to work I had to make the change to FIQLParser to ensure that
> SimpleSearchCondition was only initialized with the map of properties which
> were specified in the query given that LogRecord has the dozen (or so :-))
> of other properties. Thus I'm not sure why to fail the match if the
> property, even it is primitive, is not even checked ?
>
>
>> Since unit/system tests accidentally used all primitve type
>> fields in queries (I mean "id") everything worked fine. Now the tests are
>> broken (and disabled) because I added sanity check inside
>> SimpleSearchCondition which denies work it type T contains primitive
>> types.
>> If Book class had "id" type of Integer, instead of int, it would work as a
>> charm. But it makes too mach of a hastle and as I confirmed it is
>> unnecessary constraint I overlooked, so I just need to take care of the
>> code
>> I committed and replace comparison mechanism in SimpleSearchCondition,
>> plus
>> wire it back in FiqlParser.
>>
>> Are you saying you are ok with reverting the change ? If yes then +1.
>
>
>> Sergey, do you plan this featrue part of 2.4 release, right? Just let me
>> know what deadline is to see if I can handle this change on time.
>>
>>
> SearchConditionBuilder will be part of the 2.4 release so it will be a new
> feature, or may be rather the enhancement toward making the search feature
> more complete as it will facilitate using FIQL on the client side...
>
>
>> Regarding user perspective and how SearchConditionBuilder is a factory for
>> builders, maybe in future other than FIQL -- sounds reasonable, will take
>> care of it too.
>>
>> Sound good. I'd be glad if we could hide initial query() and introduce
> some primitive factory mechanism.
> May be we can make SearchConditionBuilder an abstract class ? Have an
> internal FiqlSearchConditionBuilder as the default instance ? And have
> SearchConditionBuilder.instance() and SearchConditionBuilder.instance(String
> language), with the former delegating to the latter as instance("FIQL") ?
>
> thanks, Sergey
>
>
>> cheers,
>> -andy.
>>
>>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
Sergey Beryozkin-5 wrote:
>
> I'm concerned about it.
> I've seen the relevant JAXRSClientSeverBookTest being disabled and I'm
> honestly not sure why
> given
> _s=id==2
>
You could use this query on "id==2" and it worked (you have made unit/system
tests). The trick is that when one would make up a query with "name==CXF*"
only, without id, this certailny fails since id is internally set to zero
instead of null Since unit/system tests accidentally used all primitve type
fields in queries (I mean "id") everything worked fine. Now the tests are
broken (and disabled) because I added sanity check inside
SimpleSearchCondition which denies work it type T contains primitive types.
If Book class had "id" type of Integer, instead of int, it would work as a
charm. But it makes too mach of a hastle and as I confirmed it is
unnecessary constraint I overlooked, so I just need to take care of the code
I committed and replace comparison mechanism in SimpleSearchCondition, plus
wire it back in FiqlParser.
Sergey, do you plan this featrue part of 2.4 release, right? Just let me
know what deadline is to see if I can handle this change on time.
Regarding user perspective and how SearchConditionBuilder is a factory for
builders, maybe in future other than FIQL -- sounds reasonable, will take
care of it too.
cheers,
-andy.
--
View this message in context: http://cxf.547215.n5.nabble.com/SeachConditionBuilder-for-CXF-JAX-RS-clients-tp3357826p3411767.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.michalec@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
Request for "CXF USE CASES" web page
Posted by robert <ro...@gliesian.com>.
It would be nice if there was a "USE CASES" web page for CXF.
On the page would be a table with all of CXF's main features and a
column for common use cases.
This would be a quick look of what is supported and why the different
features would be use.
For the seasoned CXF user, this won't bring a lot of value... but for
the CXF newbie, this will quickly help the user in going down the RIGHT
path.
I wish I could create this page and table, but I'm not well versed
enough with CXF yet, though I would be a consumer of this information.
Note: I do realize that most of this information is amongst the CXF web
pages... this would just roll everything together for a quick-look.
Example: The table could provide a real-world quick-look use case of
when/why CXF's SOAP over JMS support is used.
Thanks!
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
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"
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)"
As always I am waiting for comments.
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).
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.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Forwarding the message...
---------- Forwarded message ----------
From: Sergey Beryozkin <sb...@gmail.com>
Date: Tue, Feb 8, 2011 at 9:37 PM
Subject: Re: SeachConditionBuilder for CXF JAX-RS clients
To: dev@cxf.apache.org
Hi Andy
On Tue, Feb 8, 2011 at 7:57 PM, Andrzej Michalec <andrzej.michalec@gmail.com
> wrote:
>
> > 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.
>
>
thanks, I think the *SearchCondition*Builder might've contributed, my fault
:-)
> > 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.
>
> Please do...
thanks, Sergey
> 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.
>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
> 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.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
> 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?
>>
>
> My motivation is to use for automations and machines as well :-)
>
> thanks, Sergey
>
>
>
>> 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)"
>>
>>
I've missed this one. This is exactly what I'd like the builder help users
with, avoid typing
raw FIQL queries :-). 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
Hope you can see now my motivation
thanks. Sergey
(ok, whitespaces are not supported now, so it is an obstackle not to do this
>> during cofee break :)
>>
>> cheers,
>> -andy.
>>
>>
>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Forwarding, problems with replying to messages posted from Nabble
Hi Andy
On Tue, Feb 8, 2011 at 3:33 PM, Andrzej Michalec <andrzej.michalec@gmail.com
> wrote:
>
> I am back again.
>
> welcome :-)
> > 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.
>
>
exactly.
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 :-)
> > 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.
>
Sorry, there's a bit of confusion here, due to me not expressing the goal of
introducing the builder, at least this is how I see it.
It only needs to produce a *raw query text* for the consumption of the
client code building a request URI.
This is it. Noting else, the goal is to motivate the user start using FIQL
queries without having to understand or hard code the FIQL rules in the
client code.
Would you agree on this one ?
I'm not sure what the goal of building a SearchCondition using the builder
on the client side. On the server side it's obtained via SearchContext and
we need a typed SearchCondition there, but not on the client side...
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?
>
> Sorry, not sure about this one. As I said above I'd only like to have a
builder for letting users build a raw query.
> > 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.
>
>
Lets agree on what we're introducing a builder for first :-)
>
> > 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?
>
My motivation is to use for automations and machines as well :-)
thanks, Sergey
> 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.
>
>
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Andrzej Michalec <an...@gmail.com>.
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.
Re: SeachConditionBuilder for CXF JAX-RS clients
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andy
On Thu, Feb 3, 2011 at 9:31 AM, Andrzej Michalec <andrzej.michalec@gmail.com
> wrote:
>
> I could not reply earlier, Sergey knows I am (still) attending to my
> company's internal event ;)
>
thanks for finding the time to reply,
> 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();
>
nice, may be even matching("The Lord") because 'matching' probably means a
partial match, we can also have equalTo, similar to lessThan/etc.
However, I'd just do
SeachConditionBuilder.instance().is("title").matching("The Lord*").build();
because I'd consider
SeachConditionBuilder.instance().query(new Book())
is a shorter expression involving all the book properties:
SeachConditionBuilder.instance().is("title").equalTo("The
Lord").is("id").equalTo(123);
Effectively the Book captures the 'user input' so the builder would check
the name of all the properties and also get all the values...
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.
>
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 :-).
> 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();
>
> nice again, having type aware methods like 'before'
> 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.
>
I also propose making and() optional, if that is feasible
> 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();
>
>
sure, +1
>
> 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..."
>
> I'd have no problems with dropping an idea of "price < 20". But the reason
I proposed it was that I was not quite sure
how the transition between the phase of collecting the user input to the
actual coding stage will work in practice. For example, what the the actual
user facing form would look like and how easy would it be to code such a
transition.
I really like the fine-grained decomposition idea. I think users would
especially enjoy using for testing. But in the real application one would
probably need to do :
builder.is(getNameOfTheField());
String value = getValueOfTheField();
// something like
if (theFieldOperator == '>') {
builder.lessThan(value);
} else {
builder.greaterThan(value);
}
So I was thinking that the user just gets the "a > b" literal value
(assuming a form lets users type them) and just passes it to the builder
and as I was commenting, the javadocs would clearly state that only
primitive literal expressions are supported. Even I can write the code
enforcing it :-). Likewise, the idea of supporting PrimitiveExpressions is
similar, one just passes 3 values, name, op and value (scraped from the
form) to the constructor.
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 :-)
thanks, Sergey
all comments are welcome
>
> cheers,
> -andy.
> --
>