[MAGNOLIA-3672] Expose string property as booleans as well. Created: 28/Apr/11  Updated: 29/Apr/11  Resolved: 29/Apr/11

Status: Closed
Project: Magnolia
Component/s: core, freemarker
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Magnolia International Assignee: Philipp Bärfuss
Resolution: Not an issue Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MAGNOLIA-3672.patch    
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Testcase included:
Yes
Date of First Response:

 Description   

Since there are many places/cases where we store boolean properties as string properties in jcr (i.e a checkbox from a dialog), it's quite cumbersome to convert those in FreeMarker.

Instead of what I'd expect to write:

    [#if content.myProperty]<p>Hello world</p>[/#if]

one currently has to write something along these lines

    [#if content.myProperty!'false'=='true']<p>Hello world</p>[/#if]

... which is admittedly annoying, awkward and downright ugly.

Here's a patch that shows we could expose strings as models of both strings and booleans to FreeMarker



 Comments   
Comment by Magnolia International [ 28/Apr/11 ]

Ok, feel free to discard this issue:

  • if the dialog control is using type:Boolean, the property is indeed stored as a boolean. Guess that should be the default for a checkbox, but other than that, things are fine here.
  • to work around the fact that the property might be absent, one can do - as one would do with any other type of absent property.
    [#if content.myProperty!false]<p>Hello world</p>[/#if]
    

I probably got confused because of a double negative (and parenthesis) in my use-case:

[#if !(content.hideTitleOnPage!false)]...
Comment by Philipp Bärfuss [ 29/Apr/11 ]

I think that we have already to many of this magic transformations and that we shouldn't add yet another one. The type has to be specified properly. Lets hope for more adequate default values in 5.0

Generated at Mon Feb 12 03:48:35 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.