[
https://issues.apache.org/jira/browse/VELOCITY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855161#comment-16855161
]
Claude Brisson edited comment on VELOCITY-915 at 6/3/19 11:58 PM:
------------------------------------------------------------------
This is by design. The change is documented [in the upgrading
page|http://velocity.apache.org/engine/2.1/upgrading.html#behavior-api-changes_1].
So, yes, it's a good idea to introduce three new backward compatibility flags
(using the 2.1 snake case property naming conventions) :
{code}
# call the handler for quiet invalid references
event_handler.invalid_reference.quiet = true
# call the handler for results or values which are present but null
event_handler.invalid_reference.null = true
# call the handler for results or values which are just tested as in #if($foo)
event_handler.invalid_reference.tested = true
{code}
And, a fourth one, not for backward compatibility but for consistency:
{code}
# call the handler for values which do have an alternate value, as in
${foo|'bar'}
event_handler.invalid_reference.alternated = true
{code}
(Not being a native english speaker, I'm not sure if _alternated_ is
acceptable).
Leaving this fourth flag default value as {{false}} is certainly natural and
the way to go, but will introduce a small backward compatibility issue with
v2.1. I think we can live with it.
was (Author: claude):
This is by design. The change is documented [in the upgrading
page|http://velocity.apache.org/engine/2.1/upgrading.html#behavior-api-changes_1].
So, yes, it's a good idea to introduce three new backward compatibility flags
(using the 2.1 snake case property naming conventions) :
{code}
# call the handler for quiet invalid references
event_handler.invalid_reference.quiet_reference = true
# call the handler for results or values which are present but null
event_handler.invalid_reference.null_result = true
# call the handler for results or values which are just tested as in #if($foo)
event_handler.invalid_reference.tested_reference = true
{code}
And, a fourth one, not for backward compatibility but for consistency:
{code}
# call the handler for values which do have an alternate value, as in
${foo|'bar'}
event_handler.invalid_reference.alternated_reference = true
{code}
(Not being a native english speaker, I'm not sure if _alternated_ is
acceptable).
Leaving this fourth flag default value as {{false}} is certainly natural and
the way to go, but will introduce a small backward compatibility issue with
v2.1. I think we can live with it.
> Allow invalid reference events for quiet references to improve backward
> compatibility
> -------------------------------------------------------------------------------------
>
> Key: VELOCITY-915
> URL: https://issues.apache.org/jira/browse/VELOCITY-915
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 2.0, 2.1
> Reporter: Pierre Post
> Assignee: Claude Brisson
> Priority: Major
>
> Apache Velocity 2.0 changed the mechanism of sending invalid reference
> events. As of version 2.0, no events are generated in case of quiet
> references. As it is understandable to produce less irrelevant events for
> most use cases, there still exist some other use cases where these events
> must be received for quiet references. Besides, this was absolutely
> legitimate in versions 1.x and we now have projects that rely on that
> behavior but cannot be migrated to 2.x without further development effort.
> If there is no other way to reproduce the old 1.x behavior, please add an
> initialization parameter that enables the sending of invalid reference events
> for quiet references as this would greatly improve backwards compatibility
> with 1.x versions, e.g.
> {noformat}
> # Send invalid reference events for quiet references (false by default)
> eventhandler.invalidreferences.include.quiet_references = true{noformat}
> There already exist other parameters only to ensure backwards compatibility.
> Thank you very much.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
