From what I see it’s not a “page content header” but a “before title” UIXP.
Note: When I look at myxwiki.org for example (which is on XS 12.3) the page edit menu is on the same line as the title which doesn’t correspond to a “before title” UIXP. The reason is that the code outputs several DIVs and then there’s some CSS to reorder them.
I don’t quite agree about this one For me this UIXP is not related to the Flamingo skin but to the common templates, and thus must not have the Flamingo part in it. Said differently another skin should be able to implement this UIXP too. Otherwise it means that another skin will not be able to benefit from the UIX and it breaks the whole concept of UIXPs (which is to have reusable parts between skins and to be able to inject content into any skin and it’ll appear at the right place). This is an important topic that we discussed in the past already but it’s probably good to reassert what we want. WDYT?
- We need consistency so the question is not just about the “after content” UIXP but also the one for before the content.
- We need to decide about terminology. 2 choices: “before/after” or “header/footer”. We use both right now. For ex: “beforeContent” vs “contentHeader” and “afterContent” vs “contentFooter”.
- The before content template (contentheader.vm) currently does the following:
- display the UIXP for “before title” line
- display the title line (no UIXP ATM)
- display the last modified line (no UIXP ATM)
- display the menu line (using the menu UIXP)
- In addition there’s also the hiearchy.vm before that for the breadcrumb which is also part of the before content area.
- Have a single UIXP for before the content: “before content” (or “content header”). And it supports several UIX, with an order. Then have 4 UIXs for this UIXP:
- breadcrumb: implemented as a UIX of “before content” with priority 1
- title: implemented as a UIX of “before content” with priority 2
- last modified: implemented as a UIX of “before content” with priority 3
- content menu: implemented as a UIX of “before content” with priority 4
- This means deprecating the “before title” UIXP IMO since any UI that need to come before the title just need a UIX with a priority slightly lower than the title UIX one.
- It also means deprecating the “after content header” one (https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/AfterContentHeaderUIX) for the same reason.
- Note: The menu UIXP can stay and be used inside the UIX for “content menu”.
- Following the same idea, I would go with a single UIXP for after the content: “after content” (or “content footer”). We would have several UIX for it:
- one for the tags
- one for the “created by”
- one for the docextra part
- one for the like
- The positioning for each UIX is done by the CSS. This is why I prefer a single “before content” and “after content” so that there’s no semantic issue with the positioning (if you say “before title” and then move the title with CSS then it becomes wrong). With before/after content we just assume that the content will not move which is more likely to happen
Since after and before are problematic (as the after is the previous of the next section), we could imagine having a single “content” UIXP for all content areas, each UIX of it being a DIV and then use CSS to lay it out.
This doesn’t change all specific UIXPs, in only impacts the UIXP that are about big “content” areas (header, content, footer, panels). All the other UIXP can still be UIXPs of these content UIXs.
This is a much bigger refactoring. Although we’re not ready to go for it right now, it’s interesting to know if we want to go in this direction and start thinking how we could move to it (and how to refactor the templates accordingly).
Templates vs UIXP
We need to decide when something is a template and when it’s a UIXP. In the past we did everything with templates and more and more we are going towards UIXP so we need to be clear when we allow ourselves to add a template file and when we use a UIXP instead. And when we refactor templates into UIXP.
If you think about it and push it to the extreme there would be a single template and all the rest could be implemented as UIXP.
Back to the topic
If we agree about proposition 1 then we should implement Simon’s need using a single “after content” UIXP with order/priority and refactor at least the tags and “created by” parts into UIXs. I say at least because it would also be nice to refactor the docextra as such a UIX IMO. The issue is backward compatibility with xwiki instances having custom skins overriding the “docextra.vm” template. Not sure how we could handle this.
So to summarize my answer to the 3 questions:
- yes but provided we agree a proposition 1 (ie we need to be consistent with the before content too).
- no on 1 points (the flamingo part in the name) and not sure about “contentFooter” vs “afterContent”.