[#73909] Restructure wiki tab content for new designs#22833
Conversation
…inks' into feature/73909-restructure-wiki-tab-content-for-new-designs
- https://community.openproject.org/work_packages/73909 - add new sections - add new border boxes for all sections - add collapsing logic - add empty state for the whole tab
- use single collapsible page links component for inlines and mentions
|
Caution The provided work package version does not match the core version Details:
Please make sure that:
|
…b-content-for-new-designs
- amend page info result model - adapt page link service to return page info results
|
This PR is still bloated with the changes in #22761 . Once the other is merged, it will be reviewable. Alternatively I could set the merge target to |
Merge finished, this PR is again clean of external changes. |
| end | ||
|
|
||
| def relation_page_links_for(provider:, linkable:) | ||
| def relation_page_link_infos_for(provider:, linkable:) |
There was a problem hiding this comment.
🟡 I noticed the term "page link info" in a few places before. Is it a mix of the two real entities "page link" and "page info"?
Or is there an entity that I am not aware of, that's called PageLinkInfo?
There was a problem hiding this comment.
no, this is a naming issue, i can simply resolve....
Edit: now I remember how this names came into place. The differentiation is the prefix. We have relation page links and inline page links. And on top of those we fetch page infos. So, I already shortened it from RelationPageLinkPageInfo to something shorter. Thoughts from your side with this information?
There was a problem hiding this comment.
It's interesting that I stumbled over it in the first place... Let me write it down logically: A page link is a link to a page and I might want to have information about a page... page info.
Now what we fetch here is the information about a page that we link to... linked page info? That would give us inline linked page info and relation linked page info...
I don't say that I like these names, I am just trying to use the words as if they were actual language... And I think that "inline" and "relation" tell us how we link the pages.
Any thoughts from your side now? I think eventually I can also live with the names chosen here... Alternatively, I am trying to figure out how much I like/hate relation_linked_page_infos_for and inline_linked_page_infos_for...
| def relation_page_links_for(provider:, linkable:) | ||
| def relation_page_link_infos_for(provider:, linkable:) | ||
| provider.page_links | ||
| .merge(RelationPageLink.all) |
There was a problem hiding this comment.
🔴 I just realized that this is a valid implementation for the internal provider, but an invalid implementation for the XWiki provider, because we will not be storing relation page links for XWiki locally.
As propoposed for a different query already, I'd suggest to extract this code into a query that can be called on the provider (then it also makes sense that it returns PageInfos). We can take this implementation here for the internal wiki already, but I guess for XWiki we should go for another fake implementation.
As said earlier, I would find it great if we could push our "faking" out into the queries and commands, but have the rest of the code in "production" shape already. Because this will eventually give us a nice overview of which pieces are still missing.
Naming proposals:
provider.resolve("queries.related_pages").call(...)
provider.resolve("queries.relation_page_links").call(...)
- resolved post merge conflict errors - improve counting of page links in tab
92150bc to
d53a39c
Compare
|
I want to create now two queries. @NobodysNightmare Are you fine, if I extract both to a separate PR? |
No concern about splitting this out into a separate PR, feel free to do so. For me the most important part is, that we don't forget to do it :) |
|
PR for the referencing pages query would be here: #22899 If the only thing left here are the queries, is this approved? or is there something missing? |
|
|
||
| relation_page_links + | ||
| inline_page_link_infos_for(linkable:).size + | ||
| referencing_wiki_page_infos_for(linkable:).size |
There was a problem hiding this comment.
❗ Interesting that the referencing pages are now included. They were previously ignored.
I am not quite sure where we plan to use this number, though, so maybe it makes sense 🤷
There was a problem hiding this comment.
the number is used in the tab counter badge. And Design said explicitly to include all shown page links.
NobodysNightmare
left a comment
There was a problem hiding this comment.
Dead code (see my comment) still needs to be addressed. And potentially the naming issue around page link infos...
Apart from this, it looks good.
NobodysNightmare
left a comment
There was a problem hiding this comment.
(leaving decision on the naming and whether to include "mentioned by" in counts up to you)
Ticket
#73909
What are you trying to accomplish?
What approach did you choose and why?