Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XWIKI-22400: Support properties from other classes in Live Data #3324

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

michitux
Copy link
Contributor

@michitux michitux commented Aug 7, 2024

Jira URL

Changes

Description

  • Consider parameters that end with "_class" and load the metadata of the specified property and class.
  • Refactor the code to avoid duplication in the document loading code.
  • Add a test for the new functionality.

Clarifications

This allows, e.g., listing users together with tags while getting proper metadata (column name, filters) for the "tags" column:

{{liveData id="users" properties="_avatar,tags,doc.name,first_name,last_name" source="liveTable" sourceParameters="className=XWiki.XWikiUsers&translationPrefix=xe.userdirectory.&tags_class=XWiki.TagClass"/}}

Screenshots & Video

Executed Tests

I've built xwiki-platform-livedata-livetable with the quality profile.

Expected merging strategy

  • Prefers squash: Yes
  • Backport on branches:
    • None (new feature)

* Consider parameters that end with "_class" and load the metadata of
the specified property and class.
* Refactor the code to avoid duplication in the document loading code.
* Add a test for the new functionality.
@michitux michitux marked this pull request as draft August 7, 2024 14:03
@michitux
Copy link
Contributor Author

michitux commented Aug 7, 2024

I've noticed that there are lots of problems with the inline edit feature in LiveData. There is missing frontend support to extract the correct class reference. Then the code for saving the property on the backend also needs to be made aware of the extra class parameter. As if that wasn't enough, there is also the difficulty that the extra object might not exist. Both the loading of the edit form and the saving on the backend needs to support this case if we want to enable editing in this case. If we don't want to enable editing for this case, we need to at least disable editing.

I've marked this as a draft for now as this feature seems to contain much more than this relatively simple change. I have started writing fixes for some of the mentioned issues but all in all this seems much more than a quick fix so I'm leaving this for when I or somebody else has more time for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants