[MAGNOLIA-6039] Implement FragmentDefinition on RenderableDefinition Created: 12/Jan/15  Updated: 24/Jun/15  Resolved: 12/Jan/15

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

Type: Improvement Priority: Neutral
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MAGNOLIA-6168 FragmentDefinition on RenderableDefin... Closed
dependency
is depended upon by MGNLADVCACHE-37 Add support for FragmentDefinition Closed
relation
is related to MAGNOLIA-5839 Revise implementation of Rendering Li... Closed
is related to MAGNOLIA-6000 Implement a rendering listener which ... Closed
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)
Epic Link: DPC

 Description   

We need to know if an component/area/... is dynamic. The Default implementation StaticFragmentDefinition marks a content as non-dynamic. DynamicFragmentDefinition is part of advanced-cache, see MGNLADVCACHE-37.
The reasons to be part of RenderableDefinition and not a custom one:

  • One would need to create custom:
    • AreaDefinition (for areas)
    • TemplateDefinition (for components)
    • do the same for all custom definitions e.g. from STK
    • customers would need to do the same for their custom definitions
  • To prevent casting in rendering.

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