-
Notifications
You must be signed in to change notification settings - Fork 63
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
Filtering of single and multiple select fields #5810
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@markusweigelt : Thanks for the PR! That will help a lot to handle the missing project-specific values and roles of persons and corporations.
From the users' perspective, it works. I would prefer to apply the filter mode contains
instead of startsWith
.
For example: If the collection "Handschriften" is assigned to an object, another collection like "Französische Handschriften", "Deutsche mittelalterliche Handschriften", ... is assigned, too. It would be convenient, if all collections, which contain "Handschriften" are displayed.
Additionally, we use prefixes like "Projekt: ..." or "LDP: ..." to distinct collections. These prefixes must be known when appliying startsWith
, which becomes difficult the more collections are configured.
Would it be possible to make it configurable by applying the attributes filterable="contains"
, filterable="contains"
, ... or must it be configured in the code/backend?
@andre-hohmann I changed the default filter mode to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks lot!
In my opinion (users' perspective), it works fine.
I do not need the opportunity of configuration.
But other institutions might have a different opinion.
Ruleset already supports |
As I understand the pattern, it is only applicable for validation, but not for filtering on the client side. Correct me if I'm wrong. |
The check happens inside Tomcat, it’s not Javascript. When I wrote it, my intention was that that the metadata editor doesn’t even allow the value, but I think it changed so these checks only apply during validation. I don’t know why it changed |
However, this pull request only concerns the client-side and the filtering of the results displayed by the application. I can't imagine right now how the pattern before validation would help. Or does it essentially do what the current implementation does? |
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/KeyView.java
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/Settings.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/xml/Setting.java
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/KeyView.java
Outdated
Show resolved
Hide resolved
Although not directly related to the pull request but since this is about usabilty: It is great that this PR allows us to filter a long list, but unfortunately the editor does not immediatly see which values are already selected when the selected values are at the end of the list. Has it been considered to use https://www.primefaces.org/showcase-v8/ui/input/checkboxMenu.xhtml which seems to be a drop-in-replacement for |
@BartChris The design decisions that have been made and why these components were chosen are beyond my knowledge. It is true that it's about user-friendliness, but only for a small aspect of filtering existing lists. The mentioned component does not have such filtering, so I believe the context is not applicable here and should be discussed or submitted elsewhere, for example, in the community board. |
@markusweigelt, @solth, there is a bug report from SBB on the community mailing list:
Is this related to the PR? |
Currently, I am no longer involved in the project, so I can only make a remote diagnosis. It sounds like that. We use a cherry-pick approach for these changes in our SLUB because, for certain reasons, we do not use the current version but still need this feature. However, it was tested and developed against the state at that time. It is not out of the question that there is a bug here. Were the modules deleted or updated beforehand to ensure that the new module JAR's are being loaded? Has the server been restarted and cache problems ruled out? |
That was my first thought as well after reading the mail on the community list, since old/outdated modules have often been the cause of errors after the application has been updated in the past. I will write an corresponding answer. |
Ok, @matthias-ronge beat me to it! |
In the last conversation about a project, it was noted that the more options assigned to a key, the more cumbersome it becomes to find the right option.
PrimeFaces 8 already provides an implementation for making the select field searchable/filterable.
https://primefaces.github.io/primefaces/8_0/#/components/selectonemenu?id=filtering
https://primefaces.github.io/primefaces/8_0/#/components/selectmanymenu?id=filtering
I have made this configurable for select fields through the
filterable
attribute in the rule set. Under editing in the settings of a key, you can now set the attribute tofilterable="true"
. This will display the following filter:Example:
By default, the filter is not displayed and must be explicitly activated. After activation, the filter is displayed, and it searches for all entries that begin (not casesensitive) with the input.
There are also other Primeface filter modes that allow the entered search term to match not only at the beginning but also at the end or anywhere within the option being searched for. Additionally, you can set a custom filter mode.
If needed, these filter modes can also be made configurable, or the default filter mode of "only at the beginning" can be changed to "anywhere." It depends on which option is more prevalent.
Adjust ruleset documentation with tempory hint that option is not available in master atm. https://github.com/kitodo/kitodo-production/wiki/Regelsatz-3.x