As far as event handlers and passing the RuntimeServices in initialization.
There is no problem with that, except that the interface is optional. You
end-up with the code like EventCartridge.initialize.
May be the event handler interfaces like ReferenceInsertionEventHandler
should just derive
I remembered one more thing:
I think we wanted to include template call stack and macro call stack into
the MethodInvocationException message. There was no easy way to do it
without installing a ContextAware MethodExceptionEventHandler because the
stack info is only available from the Context.
I
One more item that we had to fix is use of exceptions to control flow.
Stuff like this: Parser$LookaheadSuccess : if (jj_la == 0 && jj_scanpos ==
jj_lastpos) throw jj_ls;
I think there was something like that in VelocityCharStream as well.
When creating exceptions for normal control flow
Thanks for the details.
I agree that the Context could be passed along with other standard
arguments. It has been done this way for backward compatibility, but
since we go 2.0, we can improve it. And even keep B.C. by introducing
new interfaces while deprecating the old ones.
It's about the
I was delaying my vote for no real reason, but now I'm clearly in favor
of pushing out another RC with the following added:
- include the Context in event parameters and deprecate ContextAware
interface (and all related interfaces and methods)
- review ASTStringLiteral implementation to
This time, it's about tools reading external resources. I'd like to:
1) have ImportSupport and ImportTool also be available in generic tools
for absolute URLs, only the view versions being able to import a
relative URL
2) have XmlTool inherit from ImportSupport, to homogenize its behavior
