cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: split expressions
Date Fri, 15 Jan 2010 11:51:56 GMT

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.


View raw message