You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@freemarker.apache.org by "Ondra Žižka (JIRA)" <ji...@apache.org> on 2017/09/28 22:42:00 UTC
[jira] [Created] (FREEMARKER-75) New built-in ?as("variableName")
to store the left-hand operand to a variable.
Ondra Žižka created FREEMARKER-75:
-------------------------------------
Summary: New built-in ?as("variableName") to store the left-hand operand to a variable.
Key: FREEMARKER-75
URL: https://issues.apache.org/jira/browse/FREEMARKER-75
Project: Apache Freemarker
Issue Type: New Feature
Components: engine
Affects Versions: 2.3.26-incubating
Reporter: Ondra Žižka
When coding templates, one often runs into a situation like this:
{code}
<#if (foo.bar.baz.expensiveCall())!false >
${ foo.bar.baz.expensiveCall() }
</#if>
{code}
Solving it with currently available things is something like
{code}
<#assign cached = (foo.bar.baz.expensiveCall())! >
<#if cached?has_content() >
Hello, ${ cached }
</#if>
{code}
In short, passing around the information that a value could not be obtained is a bit cumbersome.
What I suggest is a built-in that would capture a value of an expression on the left to a new variable and pass it along.
{code}
<#if (foo.bar.baz.expensiveCall())!?as("cached")?has_content >
Hello, ${ cached }
</#if>
{code}
The benefits is that there is need to compute the expression twice or do the assignment.
Speaking of simplicity, the expression above could also be simplified by another built-in, a "reversed" {{then()}}. (For that I will file another jira.)
{code}
${ "Hi, "?if( expensive()?as("cached"), "") + cached } // For conditional prefixes
${ expensive()?as("cached")!false + ", good bye!"?if(cached) } // For conditional suffixes
${ "Hi, ${expensive()?as("cached")!false}, again!"?if(cached) } // For conditional surrounding
{code}
The new {{?as()}} built-in could be also used for a more convenient way of assigning wile printing:
{code}
${"Hi ${user}"?as("greet")}.
${ greet }, again.
{code}
I hope my explanation does make sense.
Thanks for considering.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)