[
https://issues.apache.org/jira/browse/VELOCITY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767092#action_12767092
]
Will Glass-Husain commented on VELOCITY-739:
--------------------------------------------
Thanks for the comments,
I think there's a pretty good argument for having "strict" ignore silent
references. After all, the template author is explicitly calling out a silent
reference as "may or may not be present" and doesn't need these called out as
errors.
In my templates, at least, we make little distinction between null and invalid.
The example given ($user) is a good one. If a user is logged in, $user is in
the context. If not, there is no $user.
Right now silent references are basically useless if you want to strictly check
references.
Still, I'm late to this party so am reluctant to strongly advocate this. I'll
leave this bug open, see if Byron or others actually using this feature chime
in.
If we can make the change in SIMULATE-740, then I'm ok with leaving strict mode
as is. That provides a mechanism to do a pseudo-strict mode that flags errors
for regular references and ignores silent references.
> Do not throw exception for quiet references in strict reference checking mode
> -----------------------------------------------------------------------------
>
> Key: VELOCITY-739
> URL: https://issues.apache.org/jira/browse/VELOCITY-739
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.2
> Reporter: Will Glass-Husain
>
> I used strict reference checking for the first time and discovered that it
> throws exceptions even for quiet references.
> <input class="signupInput" type="text" id="StxtFirstNames"
> name="firstName" value="$!user.firstName"/>
> org.apache.velocity.exception.MethodInvocationException: Variable
> $user has not been set at layout/slide_login.vm[line 13, column 117]
> This doesn't make sense to me. If a template author designates a reference
> as quiet, it's explicitly not an error. We're preventing the use of this
> convenient feature.
> It's not a hard change to fix this. Does it break backwards compatibility if
> we change this?
> Incidentally, there's an identical problem for InvalidReferenceEventHandler.
> I'll file a separate issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
