As @SvenSchatter pointed out, we are also using a similar approach to render our nested macros, where we fetch the storage format of the macro and use the /view API to convert the content which we use it render. We follow this approach as we want to provide support to our server customers migrating to the cloud, who has nested macros in their instances. Having the appropriate javascript is vital for our nested macros to render as they render today.
I would request that the approach be âsane defaultsâ and a vendor can do the work of extending to do something special. Asking every vendor to support this is going to be yet another platform disruption for vendors who get no benefit from this feature.
This is how it currently works for each of the macro types. App developers are responsible for implementing the export_view format for their macros, and I donât see how it would differ for multi-bodied macros. Unfortunately, we canât force them to implement it.
To clarify, multi-bodied macros do not offer a solution for how they will be rendered inside other macros. They only provide a solution for rendering their own content bodies. Furthermore, we will not allow the nesting of multi-bodied macros or placing them inside other bodied macros.
It will still be possible to convert the page that contains a multi-bodied macro to another format, but it wonât differ from other macro types.
@Karthikeyan, this is the main idea of multi-bodied macros: to avoid nesting and usage of convert API. Consider a conversion path from nested-bodied macros to multi-bodied macros instead.
This is probably needed by other apps, but our apps always operate with the full storage format of a given page. Therefore, we would probably not be directly interested in this specific endpoint.
That is true, but what you can do is provide âsane defaultsâ as @BorisBerenberg called it. I of course donât know what the storage format of these macros will look like, but letâs assume it will look something like this:
<ac:structured-macro ac:name="some-multi-bodied-macro" >
<ac:rich-text-body>
<p>Body number one.</p>
</ac:rich-text-body>
<ac:rich-text-body>
<p>Body number two.</p>
</ac:rich-text-body>
<ac:rich-text-body>
<p>Body number three.</p>
</ac:rich-text-body>
</ac:structured-macro>
Then, if the app developer has not specifically implemented an export format themselves, a âsane defaultâ result of a conversion to export_view could look something like this:
<div class="multi-bodied-macro" data-ac-name="some-multi-bodied-macro">
<div class="macro-body">
<p>Body number one.</p>
</div>
<div class="macro-body">
<p>Body number two.</p>
</div>
<div class="macro-body">
<p>Body number three.</p>
</div>
</div>
This would allow apps like ours to work with the multiple bodies and at least try to display them in some generic way. Does this make sense?
If you donât do something like that, we will probably have to extract the n macro bodies on our side and then do n additional REST calls to the conversion endpoint, manually converting the storage format of each macro body. This would both slow down our products as well as put more stress on your REST API, so I sincerely hope that it is possible for you to provide a âsane defaultâ like this.
Cheers,
Sven
EDIT: Okay, we could probably optimize this and put all the macro bodies into the same conversion REST call, but it then would still always be one additional REST call for every page that has a multi bodied macro. So, sane defaults like mentioned above would definitely be appreciated.
Thanks for the suggestion, @SvenSchatter. This might be a good solution to proceed with.
The only concern that I have is that this approach doesnât match the current behavior for bodied macros. When renderModes are not defined, the view mode is rendered instead (resulting in an IFrame). However, I think it makes more sense to render export_view of the macro content instead, which would align with your suggestion.
@OleksandrBeztsinnyi I understand your concern and I also think that the current behavior of single bodied macros is suboptimal. It would indeed be very nice if both macro types could follow the same approach and render the body by default. Iâm not sure if this is in your scope of reach, but for our apps - and I think actually for all apps working with export_view - getting that implemented would be very helpful and amazing.
Of course, not sure if youâre actually going to implement it this way, but at least Iâm very happy to hear that you think this makes sense. Thanks for listening and replying so actively in this RFC!
Thanks for all your comments and feedback. It was really helpful to read your thoughts and better understand which aspects of the implementation are important to you.
Based on your feedback, we havenât identified any major issues that would significantly alter the approach described in this RFC.
However, in future releases, we will be focusing on addressing the following items raised in your comments:
AC JS API to retrieve and update macro bodies
Exporting pages with multi-bodied macros to PDF and Word
Exporting multi-bodied macros to view and export_view formats
Displaying changes made to multi-bodied macros in page history and email notifications
Rendering multi-bodied macros on the mobile app
We hope that the new multi-bodied macro type will help you to build better user experiences for content formatting. This can be achieved by creating brand new macros or migrating existing nested-bodied macros into the new editor.
As for the next steps, we are actively working on releasing the first version of the multi-bodied macro and anticipate starting the Early Access Program (EAP) in early 2024. During the EAP, Marketplace partners will have access to preview the feature through the Developer Canary Program.
