[MGNLADVCACHE-37] Add support for FragmentDefinition Created: 09/Jan/15  Updated: 15/Apr/15  Resolved: 13/Jan/15

Status: Closed
Project: Advanced Cache
Component/s: None
Affects Version/s: None
Fix Version/s: 1.7

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 MSITEMESH-21 Fragment configuration via dialog was... Closed
dependency
depends upon MAGNOLIA-6039 Implement FragmentDefinition on Rende... 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)
Date of First Response:

 Comments   
Comment by Jan Haderka [ 12/Jan/15 ]

I'm pretty sure that having properties called dynamic or mechanism will conflict with regular fields at least for some users.
As for ${TTL}, there I'm not even sure if it is always valid property name.
Either way, I think it would be more beneficial to have all such special properties defined in a mixin and with mgnl: prefix to prevent any possible conflicts. WDYT?

Comment by Roman Kovařík [ 13/Jan/15 ]

Shouldn't we drop that dialog configuration in the end? We wouldn't need to:

  • touch JCR at all
  • have some per dialog permissions
  • have so complex logic in info.magnolia.module.advancedcache.rendering.FragmentInjectionListener#shouldInclude
    And maybe it'd also to prevent confusion when something is configured in both definition and dialog?
Comment by Jan Haderka [ 13/Jan/15 ]

ok. easiest solution is often the best => drop it

Generated at Sun Feb 11 23:10:22 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.