Open PRGfx opened 2 years ago
I played around a bit with a more dynamic cache identifier and that works fine in itself, however I am now aware, that the rendering (root.ajaxify
) does of course not know the content-nodes and I'm not sure how best to "recreate" a contex.
As this is all basically just a caching layer, I think the wording from the caching context would make sense (entryIdentifier
, context
). So maybe a Ajaxify
component which serializes a context
as the fusion runtime (or rather the ContentCache
does). Unfortunately I don't see good ways to re-use any of this and I'm not sure rebuilding this behaviour makes sense at this point.
Any other ideas on how to achieve this?
If there is a node != documentNode, I could go for a more low-budget solution of storing that identifier and getting it from the document later, I think, but that feels like it will be limited with the next use-case.
With 8811c03 I drafted a concept on how to handle dynamic cache-identifiers and how my approach could be used with content-nodes. However it does not satisfy my concerns regarding other rendering-relevant context variables: it only includes the content-node in the ajax request and exposes its contextPath doing so. Because of that I won't open a PR for now, but will leave the fork as an example.
From my understanding, the content is only cached by the name of the
@process
configuration, so it is not really viable to use it for normal content-elements.I could imagine a system of configuring a custom cache identifier, i.e. passing it down to the
RenderPath
prototype:with some default values:
and the
RenderPathImplementation
building the entryIdentifier from the existing key and the (non-nullable, stringified) identifier parts.Is this a sensible approach or am I missing something and this isn't even actually necessary?