[MAGNOLIA-6133] Interfaces TemplateDefinition, RenderableDefinition and others in info.magnolia.rendering.template.* are using Boolean and should provide better defaults Created: 19/Mar/15  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Magnolia
Component/s: rendering
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Philip Mundt Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Most interfaces (and their implementations) in info.magnolia.rendering.template.* use Boolean rather than the primitive type boolean. When instantiated by Node2Bean, those properties will be null (when no explicitly configured) causing problems all over the place.

We should provide better defaults!



 Comments   
Comment by Magnolia International [ 19/Mar/15 ]

So we need to have the "defaults" implemented by logic in client code, which probably means we're risking inconsistencies if such an object has different clients. On the top of my head, a couple of long-shot ideas:

  • hint the "merger" with annotations on such fields (@Default(Boolean.TRUE) private Boolean theField
  • move the default-value-logic to some utility specific for the type in question
    • the "merger" could somehow know about those and utilize them (in fact, I think we have something like that in STK... for site definitions ? (IIRC an object that implements the interface and provide all defaults "hardcoded")
Comment by Jan Haderka [ 29/Jul/15 ]

hinting with annotation is interesting, but should be really a "last resort".
What typically happens is that you have component that might have some value set, if not it will be merged with whatever is inherited from the parent (when inheritance is enabled) and otherwise it is merged from site configuration (or from resolved variation of site configuration) allowing you to have different defaults for different sites or even different variations of site (e.g. mobile vs. desktop). This kind of flexibility is important to preserve for the clients so they can hold magnolia based sites into whatever they need for whichever target device.

Comment by Roman Kovařík [ 19/May/22 ]

Hello,

This ticket is now marked as closed due to one of the following reasons:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you.

Thank you,
The Magnolia Team

Generated at Mon Feb 12 04:11:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.