UI extension point for the content header

Development
,
1

Hi everyone,

There was a discussion some time ago about the org.xwiki.platform.template.contentFooter UIXP launched by @surli where, aside the main questions raised, @vmassol pointed out it could make sense to introduce also a contentHeader UIXP. I find this proposal quite interesting :slight_smile: so I’m following up here.

The content footer consists currently entirely of UIX (LikeUIX, PageTagsUIX and PageAuthorsUIX by default), which is very handy. In order to make the content header as dynamic as the content footer, what do you think about introducing an UIXP org.xwiki.platform.template.contentHeader? The content header would then contain the following UIX by default, as mentioned by @vmassol:

  • breadcrumb: content header UIX with order=100
  • title: content header UIX with order=200
  • last modified: content header UIX with order=300
  • content menu: content header UIX with order=400

Imho this approach would bring the following improvements:

  • Align the content header and content footer approaches
  • Let the content header benefit from the power of UIXs (ease of UI customization, async rendering options, cache control, ability to insert an UIX via the UIX Extension macro etc.)
  • Make it easy to implement common layouts with an image in the content header like the Facebook banner layout or this layout on LeMonde.fr, or a header combining an image with the title and other header information like this one by National Geographic.
  • Other UIX we could think of in the content header:
    • Information messages before the content such as this example on VueJS documentation: “You’re browsing documentation for v2. For v3 click here.”
    • Navigation bar for navigating to next page / previous page (as a complement or replacement of the breadcrumb in some specific cases)
    • Call to actions that are specific to the current document
    • Display PageTagsUIX or LikeUIX in the content header rather than in the footer, etc.

If we go for it, we could deprecate the UIXP After content header in favour of this new UIXP, hence the total of non-deprecated UIXP would remain the same (no complexity increase).

Do you see any downsides in organizing the content header along this line? What do you think?

Cheers

Stéphane

2

Sounds good, so +1 from me. I’m not sure though if the deprecation has any benefit apart from making sure that new code doesn’t use it anymore as this is an API and we cannot break API so I don’t think we can drop the code for this UIXP, in particular as it is heavily used from what I understand for injecting various invisible UI components (which might not be a good idea, but this is another topic).

1 Like
3

Thanks. Indeed, deprecating the UIXP After content header would be just to discourage new code from using it. I don’t think it’s heavily used, I know of the Page Relations app which uses it, not sure if it’s currently used by any other extension, are you referring to another one maybe?

4

I think I have confused this with the org.xwiki.platform.template.header.after UIXP which is used in various places. However, there is the replication application that uses the after content header UIXP.

5

Sounds good.

Yes, the Replication Application currently inject a org.xwiki.platform.template.content.header.after uix to warn about documents having a conflict, but deprecating the uixp does not mean it won’t work anymore so it’s fine for now.