Ticket #2073 (new defect)

Opened 10 years ago

Last modified 10 years ago

Partially cache portlets guard

Reported by: gracinet Owned by: jmorliaguet
Priority: P2 Milestone: CPS 3.5.7
Component: CPSPortlets Version: TRUNK
Severity: minor Keywords:

Description (last modified by gracinet) (diff)

Of course, the portlet guard outcome should stay out of the lookup cache, because it's either impredictible (full power of TALES expressions) or would generate too much keys (permissions & roles).

That being said, the most common use-cases for the guard are:

  • finer control on where in the documents tree the portlets should be rendered than what the lookup system provides (example : in all of sections but not in sections/excluded)
  • better maintainability through GenericSetup (making global a portlet that could be local, happens in CPSDefault)
  • view type control through published (typically folder skinning testing that the user is on folder_view, happens in CPSDefault)

There should be a control on the guard edit form allowing the expert user to declare that such a guard is actually cacheable and use it in the cache handling system.

Currently, the criteria would be that the guard depends on bottom-most-folder relative path only. We could add published to the cache keys.

With CPSDesignerThemes cutting the themes rendering to negligible times, on a hierarchy of sections, together with heavy portlets rendering cache, this could make a difference.

Implementation is rather easy, especially while the code is fresh in our minds (see #2052)

Change History

comment:1 Changed 10 years ago by gracinet

  • Description modified (diff)


Note: See TracTickets for help on using tickets.