[MGNLSTK-668] tocMarkup.ftl crashes on call Created: 22/Jul/10  Updated: 23/Jan/13  Resolved: 22/Jul/10

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: paragraphs
Affects Version/s: 1.3.2
Fix Version/s: 1.3.3, 1.3.4

Type: Bug Priority: Major
Reporter: Ondrej Chytil Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
caused by MGNLSTK-659 Paragraphs using the tocMacro.ftl are... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

assign rootDef = model.root.def!false

if rootDef.mainArea?if_exists

rootDef.mainArea cannot be tested for existence in this form.
Also deprecated freemarker built-in if_exists is used.



 Comments   
Comment by Philipp Bärfuss [ 22/Jul/10 ]

Note that freemarker allows the following:

(model.mainArea.intro.showToc)!false

In this case it falls back safely no matter which part of the expression is null. The same can be done for ?? expressions.

Comment by Jan Haderka [ 23/Jul/10 ]

FreeMarker docu for missing_value_test operand says

With non-top-level variables the rules are the same as with the default value operator, 
that is, you can write product.color?? and (product.color)??

so yes it can be done for ?? expression as well. But there is actually no need for the first if/else block in the macro at all.

Comment by Philipp Bärfuss [ 23/Jul/10 ]

That is what I tried to say, don't chain if statements just use the brackets instead.

But be careful the two expressions mentioned above are not the equivalent (I verified that).

Under the condition that product is not defined

product.color?? --> fails with InvalidReferenceException: Expression product is undefined
(product.color)?? --> evaluates to false

Comment by Jan Haderka [ 23/Jul/10 ]

What I tried to explain was that according to the docu ?? behaves in regards to surrounding brackets same as ! ... I'm glad we agree on that

Generated at Mon Feb 12 13:39:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.