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
This archive was generated by hypermail 2.0.0 : Fri Jan 15 2010 - 06:52:33 EST