Forwarding, problems with replying to messages posted from Nabble
Hi Andy
On Tue, Feb 8, 2011 at 3:33 PM, Andrzej Michalec <andrzej.micha...@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.
>
>
