On Tuesday, Oct 21, 2003, at 18:38 Europe/Rome, Andrus Adamchik wrote:
>
>>> Another related topic. We were planning to allow expressions encoded
>>> as strings (e.g. "xyz.abc = ..and mnk != %@", you see what I am
>>> talking about). I wonder how we can express the case above (and more
>>> complex ones with splits) in this format as well? Add an operator for
>>> "match all" or something? (SQL has "ALL" operator, maybe use it too?)
>>
>> Excellent question; I was forgetting about this topic altogether, as
>> we
>> never use it in EOF as it was missing a fundamental feature: being
>> able
>> to extend the string analyzer, in order to be able to create newly
>> coded Expressions within the same procedure.
>>
>> What I would have like to have in EOF was a way to be able to tell the
>> framework that the syntax "xyz.abc = (80, 30, 4)" should have create
>> an
>> instance of MatchAllValuesQualifier.
>>
>> Besides what the final syntax will look like, I will like to sort out
>> a
>> way to have a collaborative process (between all defined subclass of
>> Expression) to transform strings in Expressions, thus allowing newly
>> created Expression subclass to have the option of joining the
>> translation process.
>>
>> No idea on how to implement this, yet, but I will try to think on how
>> to include it in the code I am writing.
>
> Handcoding a parser in Java is probably not good anyway. I would
> suggest
> using JavaCC grammar (an analog of UNIX lex/yacc). We are currently
> using
> similar approach when doing plist parsing (see Parser.jj in
> wocompat/parser).
>
> Custom extensions can be coded by providing alternative grammar (much
> easier than writing a parser from scratch). Parser.jj file compiles to
> a
> Parser.java file, which in turn compiles to Parser.class. A user can do
> this with his own grammar file and install his own Parser class by
> calling
> a static method somewhere in expression package.
I was thinking about a more collaborative process.
The Expression class could collect a list of available subclasses, and
pass each the string to parse; if the current Expression can understand
the initial part of the string, returns the relevant Expression
instance and the string left to parse.
At every step, the root method should pass also the cumulated
Expression build until then, and let it grow with the newly created
instances of the Expression subclasses.
This reminds me of another important feature I would love to see in
Cayenne: fetch specifications stored on the model.
Having a way to encode a full expression in one string should allow to
handle the fetch specification on the model quite easy; all that is
left to do is to specify the sort ordering and eventually the fetch
limit.
I will let you know if I make any progress on this question. I don't
think I will have much time in the near future (this and next week),
but I will keep you updated on any progress.
Giulio Cesare
This archive was generated by hypermail 2.0.0 : Wed Oct 22 2003 - 01:43:50 EDT