Personally, i feel that templates whose macro calls don't match up to
the macro definitions are *already* broken. The fact that we are
escalating the response to that brokenness doesn't feel wrong to me.
Previously they were warned in the logs (think of it as deprecation)
and now the flexibility should by default be removed.
In other words, i think it should throw an exception by default in
1.5. But if you really want to provide a work-around for those with
broken templates to leave them broken, then a runtime config property
is fine with me. i would suggest a property key that fits the pattern
of the other velocimacro config options and, of course, a default
setting of "true".
velocimacro.break.on.invalid.argument.count = true
i like the idea of having a "strict" mode property for unresolvable
references, but i don't see invalid velocimacro calls as parallel to
that. the former is a issue with interaction between Model and View,
the latter is a strictly View rendering issue (and therefore a syntax
problem IMHO).
On 3/20/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Wanted to ask for some quick feedback on VELOCITY-435. One of the
> directions for Velocity 1.5 that's emerged is better error handling. Most
> stuff that used to be logged can now be trapped and reported. One exception
> is macro callswith an invalid numbers of arguments. Error messages are
> buried in a log, there's no way to trap them and make them more visible.
> Example error:
>
> #macro(foo $a) $a #end
> #foo("test1" "test2")
>
> Ideally, this would throw a ParseErrorException, but it can't due to
> backwards compatibility. (lots of existing templates with this problem would
> break). This would enable functionality like this (courtesy of Malcolm
> Edgars)
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
>
> Some solutions - any feedback?
>
> (1) yet another configuration option
> runtime.macros.strict = true
>
> (2) yet another event handler. I've already got an
> "InvalidReferenceEventHandler" in progress, this could be a new method for
> that.
>
> (3) something more creative?
>
> Thanks, WILL
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> [EMAIL PROTECTED]
> www.forio.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
