Nathan Bubna <[EMAIL PROTECTED]> writes:
>is this going to cause any problems for people who write their own
>directives? and if so, can we provide a deprecation path for them?
Actually yes, it is. The problem would be that currently
o.a.v.r.parser.node.Node is part of the visible interface.
In the changes that I've already put in, I worked around this by
keeping the name and package and just extending o.a.v.r.parser.Node
This is simply not possible when fully separating the code
out. Because the whole parser code _must_ go into a single
package. And because it does so and because <this package>.Node will
be auto-generated, the currently o.a.v.r.parser.node.Node must be
renamed. So this will break custom directives.
I don't even see a possible deprecation path, sorry. I'm very open for
suggestions here.
[...]
>> - The current "Node.java" interface is an extended version of the original
>> Node. If we want to keep the auto-generated files clean, we must just
>> rename
>> it to VelocityNode and extend the autogenerated Node interface.
>>
>> We also lose jjtOpen, jjtClose, jjtSetParent, jjtGetParent, jjtAddChild
>> jjtGetChild, jjtGetNumChildren, jjtAccept from this VelocityNode
>> interface as they are defined in the generated Node.
>>
>> - in SimpleNode, the jjtGetParent changes its Signature from
>> VelocityNode to Node, Same goes for jjtSetParent(Node n), jjtGetChild(int
>> i)
>> and jjtAddChild(Node n, int i)
>>
>> now there are a bazillion errors with jjtGetChild and returning the
>> wrong type for all the parser nodes. So we add a getChild(int i) method to
>> SimpleNode and VelocityNode, which does the same as jjtGetChild(int i) but
>> returns a VelocityNode instead of a Node. Replace all jjtGetChild()
>> occurences in the VelocityCode (can also be done with Eclipse
>> Refactoring).
This part is already in, but because the packages are different, there
are no user visible changes.
>> - As the ParserVisitor class fell behind the changes in the Parser because
>> it was not autogenerated, the visitors in parser.visitor now have a number
>> of missing methods. Add visit() for ASTEscapedDirective, ASTEscape, ASTMap,
>> ASTIntegerRange and ASTStop to NodeViewVisitor and BaseVisitor. This is
>> IMHO a logic bug BTW which would've been caught by ParserVisitor being
>> autogenerated instead of manually.
I've updated ParserVisitor to match the auto-generated class but kept it in the
node package. This also updates the visitor classes.
>> - Adding code to the ParseException wasn't really a good idea. Factor the
>> template code out into an TemplateParseException, also cleaning up the
>> code a bit. There are some hints in the JavaCC manual about customizing the
>> error messages, I will dig into this.
I've cleaned that bit up too, in the progress I've broken and updated
the MacroParseException :-)
>> If no-one objects loudly, I will apply these changes tomorrow.
After looking into the directive problem, I will not apply more
changes (the stuff that is in there should be either not user visible
or be a real improvement (line/column/template for exceptions). As I
know only of Will to actually use custom directives, I want to check
with him first.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
