Create an extension point for the "After content" area

Development
#1

Hi everyone!

I recently encountered the need of adding some elements just after the page content but before the footer.
Content Footer extension point does not help because it rather expects small items to fit in a line, while my other solution was to customize the contentview.vm file in the Skin but this needs attention on upgrades. The following image expresses better my need
image

Late Edit:
I am actually looking to add a heading See also and to be able to navigate to it using TOC.

Would this be useful enough be to implemented in XS?

Thanks,
Alex

#2

Hello @acotiuga

for me the UIXP is about the place where to put something: IMO in your case you really want to put stuff in the Content Footer so that’s the UIXP you should use with the appropriate priority, and most probably with the appropriate CSS.

Do you mean that there’s no way right now to add stuff in there that would be displayed on a separate div? Would be a big limitation of the UIXP IMO.

#3

@surli I can add my elements using the Content Footer, but adding CSS rules to change the default layout would also add complexity at upgrades. Other UIXPs do not require restyling the standard code in order to fit new content.

#4

Looking at the code the content footer might be limited as it is inside the footer container but to me it doesn’t look too difficult to add styling to work for your use case. Basically, I think what you would need to do is to add an element that has a low order such that it is first and then apply a flex-basis: 100% style on it to force it in its own row. Further, you would need to reset the font size and color to the base values (like @font-size-base) if you want the content to look the same as the rest of the document. Would that work for your use case?

#5

@MichaelHamann @surli thanks for you suggestions!
I can see an improvement from overriding a .vm file to using the existing Content Footer UIXP + little amount of CSS, so for now I will apply this.

#6

Actually, I just realized what was my biggest problem which cannot be fixed by using the existing footer UIXP: I have another element See also which is meant to behave like a heading in the page and to have an entry in the TOC. The TOC macro only generate entries for the headings in the document content, while the information in footer is out of it.
Sorry for missing the most important part that made my propose this.
So this would be an updated screnshot
image

#7

But how does your original proposal help with that TOC requirement?

My understanding is that for the TOC macro requirement you would need a way to actually insert blocks into the XDOM in a way such that they are available when the TOC macro is executed. I’m not sure we have any way to do this right now apart from inserting a macro at the bottom of every document. I assume even with an XDOM transformation that is executed before the macro transformation you cannot do that as you wouldn’t know if you are at the top-level XDOM of a document or not.

#8

This could be done with a sheet, but then you need to apply it on all your pages, and it also influences how those pages are edited (no in-place edit, Inline Form by default). There’s no notion of “default sheet” for a plain wiki page → this is done from the Velocity templates.

#9

Maybe it could be an interesting idea to provide extension points or events within the main document’s (or sheet’s) content. I haven’t checked how feasible this is, but what I imagine is basically a way to inject blocks into the XDOM of either the sheet or the document that is displayed as the main content (i.e., not included documents, comments or other parts of the document that are executed in isolation). This could either be a real UIXP or also an event that just gets the XDOM. At least for the event, it could also be interesting to have this both before and after the transformations are executed. This would also require XRENDERING-78 to ensure that the inserted content is not persisted during WYSIWYG editing.

#10

Note that right now we have a mechanism to inject XDOM blocks, it’s the Rendering Transformation API.

#11

Yes, but I think with this it is hard to decide if what you’re transforming is the main document, some panel item, the content of a cache macro, … That’s why I suggested to explicitly call this only for the main document and not also in all these other cases.