Content Completion: Cache Invalidation

[cforney]

Hi everyone,

we are using Content Completion in our project by calling an external XSLT script, as described in the docs.

Example:

Code: Select all

<xslt href="https://the-backend.com/api/values.xsl" useCache="false" action="replace"/>

For performance reasons, we would like to set @useCache to "true". Unfortunately, I did not find a more detailed description of the cache behavior.

In particular: Can you tell me on which events the cache is invalided and if there are ways to enforce invalidation manually?

Best, and thank you! Chris

[alex_jitianu]

Hi,

The computed values are kept in a cache where the key computed from all the conditions set on the match element, like elementName, elementNS etc:

Code: Select all

<match elementName="lg" elementNS="http://www.oxygenxml.com/ns/samples">

The cache is associated with the editor. Because it is associated with the schema, events that normally reset the schema related caches will drop this cache as well, for example the Validate action.

I will add a note in documentation about this behavior.

Best regards,
Alex

[cforney]

Thank you for the useful explanation, Alex. It's good to know that validation also drops the cache.

I would like to ask a follow-up question here:

We found that caching does not take into account the context set by <xsl:variable name="propertyElement" select="saxon:eval(saxon:expression($contextElementXPathExpression, ./*))"/>. In many cases, @useCache="true" will therefore offer incorrect value lists. Is there a way to cache context-aware?

I should make an example. We have two different data fields in one document, both encoded with note/@ana:

Code: Select all

<note n="dataFieldA" ana="value-from-valueListA"/>
<note n="dataFieldB" ana="value-from-valueListB"/>

But because caching does not take into account the context of $propertyElement, only one value list will be considered; in our case the values from valueListB were suddenly offered for note[@n='dataFieldA']/@ana when using the caching feature.

[alex_jitianu]

Hi,

Yes, you are correct. The caching mechanism doesn't take into account the XML document context, just match criteria, which makes caching not suitable when you base your values on the XML context.

I'm not sure how to build the cache key in this case. We can't use $contextElementXPathExpression because it's an expression like /root[1]/note[2]. Altering the XML structure will lead to bad proposals. We might build a key in which we use the other attributes , like in your example n="dataFieldA". But it will still cache badly for situations in which, from the XSLT, you make conditions based on ancestors or siblings.

I will add an issue to further discus this.

Currently, as a workaround, you can use our Java based API to implement a Content Completion Handler that knows how to properly cache the values.

Best regards,
Alex

[cforney]

Thank you again for your answer. I wasn't aware of that, but it's great to have the possibility to interact via Oxygen's Java-based API and to implement a custom Content Completion Handler. Unfortunately we are lacking the skills needed in our team at the moment.

From our project point of view, we would certainly welcome if cache keys are based on attribute combinations. This would cover not all, but the vast majority of our use cases. In any case, we will follow further Oxygen developments in this area with the greatest interest.