No need for indexing of our macro data.
Note most of our high usage macros are interactive and have a link the opens a forge modal to interact with the data. Unless the static macros can do that (similar to a byline) we likely will have to stay with the dynamic macros.
Hi @mtalebi ,
We currently don’t need indexing.
Hello!
Yes, search indexing is important for our use case. Our customers rely on being able to discover information that is rendered by the macro through Confluence search, so having the macro’s rendered content indexed would be valuable.
Regarding configuration, I think indexing should either be enabled by default or be configurable per macro. Having an option in the manifest to opt in or opt out would provide the necessary flexibility for different use cases, while still allowing apps that depend on searchability to enable it.
Thanks for considering this feedback.
Hi @StepanBogatrjov,
Re:
Should snapshots be considered shared page-level state or user-specific state?
snapshots can’t be user-specific specially given your requirement for search indexing.
Also re,
when user interactions modify only the presentation of the data rather than the underlying data itself
How is this working in connect staticContentMacro currently? Isn’t this stored somewhere probably as part of config?
In Forge, if user interactions can modify the view for that particular user, still need to leverage dynamic macros.
Search indexing matters for some of our static macro use cases, especially when the macro renders meaningful visible text that users would naturally expect to find through Confluence search.
I would prefer indexing to be configurable rather than always on or always off. Some macro output can be noisy, sensitive, hidden, or not useful for search.
@mtalebi Hi Mary, on another thread we are working with the adfExport function in new forge macros to get Word exports working cleanly. As part of that we ran into this legacy bug that Confluence was rendering adfExport for old connect macros during the page rendering. (https://jira.atlassian.com/browse/CONFCLOUD-83809)
It occurred to us that if adfExport could be used intentionally this way (rendering for live view) in lieu of an iFrame that would basically give us the static macros back. It would be so much simpler than the staticView described in this RFC. Perhaps there could be a TTL returned from the adfExport function that Confluence could cache the content for. This approach feels so much cleaner and more efficient then trapping related page update events to pre-calculate and write output into a custom content cache that may never be requested or seen.
It also simplifies the word, email export cases to know the adfExport will be used for those. In our legacy app we needed different formatting for word vs pdf export and it is not clear in the RFC how that would be supported with a single cached staticView value.
Just a thought
Chris
Hi @mtalebi ,
I’m also in support of @Chris_at_DigitalRose proposal.