On Jan 15, 2010, at 11:05 AM, Andrus Adamchik wrote:
* ASTs are generic and not very intuitive for direct manipulation in
API. A good analogy would be DOM trees vs. real object models
represented by those trees.
* ASTs often have slight differences in structure compared to an
ideal domain object. This is more pronounced in EJBQL, that has
AST's for SelectClause and other irrelevant nodes on the tree
(irrelevant to the user of course)
* Due to the use of JavaCC as a parser, we have this odd looking
method names inherited from the parser Node class (e.g.
org.apache.cayenne.ejbql.parser.Node)
Answering my own question (I hope)... I don't remember all the history
by now, but actually this might be the case when we went along with
the framework-provided convenience, ignoring its downsides. We are
using JJTree syntax - a JavaCC preprocessor that allows to build ASTs
"out of the box". I think if we take a step back and use straight
JavaCC, we can create arbitrary domain objects at the expense of extra
code and reduced parser clarity. Or we can keep using JJTree and do a
postprocess conversion of AST to domain object, at the expense of
performance (similar to SAX vs. DOM choice I guess).
In any event we need to experiment modeling EJBQL (and potentially
Expressions) as "AST-free" domain objects and see how that works,
before rewriting the parsers.
Andrus
