[ https://jira.nuxeo.com/browse/NXP-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=92567#comment-92567 ]
Alain Escaffre commented on NXP-4935: ------------------------------------- Other use case: be able to leverage translations of label that would be input by a functional administrator) > Rewrite selection/directory widget types > ---------------------------------------- > > Key: NXP-4935 > URL: https://jira.nuxeo.com/browse/NXP-4935 > Project: Nuxeo Enterprise Platform > Issue Type: Sub-task > Components: Layouts / Widgets > Reporter: Anahide Tchertchian > Fix For: 5.4.x > > > 2.5.1 Selectionwidgettypes > > For now there are no widget types using simple selection components (expect > the > boolean checkbox widget type). There are 6 JSF components of interest in this > mat - > ter: > - h:selectManyCheckbox > - h:selectManyListbox > - h:selectManyMenu > - h:selectOneRadio > - h:selectOneListbox > - h:selectOneMenu > Each of these components could be mapped to generic widget types. The > difficulty > is about expressing available values. > There are two standard ways of declaring available values on these components. > Using tag "f:selectItem" for each available selection: > <h:selectOneRadio value="#{field_0}"> > <f:selectItem itemValue="imap" itemLabel="IMAP" > itemDisabled="true"/> > <f:selectItem itemValue="pop3" itemLabel="POP3" /> > </h:selectOneRadio> > Using tag "f:selectItems" for all available selections: > <h:selectOneRadio value="#{field_0}"> > <f:selectItems value="#{mySelections}" /> > </h:selectOneRadio> > Any number of these tags can be combined to add selection values to the > global se - > lect. Nuxeo add two kinds of tags to these standard select items. > A first one makes it possible to build selections from any kind of object > list (and not > only a map for instance): > <h:selectOneRadio value="#{field_0}"> > <nxu:selectItems value="#{myDocumentList}" > var="document" > itemValue="#{document.ref}" > itemLabel="#{document.dublincore.title}" /> > </h:selectOneRadio> > A second one makes it possible to take into account directory values. It also > support > filter of obsolete entries, and usage of a sort criterion: > <!-- show the subject directory entries --> > <nxir:selectItems directoryName="subject" > var="item" > itemValue="#{item.id}" > itemLabel="#{item.vocabulary.label}" /> > <!-- show the subject directory entries filtered by given list --> > <nxdir:selectItems directoryName="subject" > value="#{document.dublincore.subjects}" > showAll="false" > var="item" > itemValue="#{item.id}" > itemLabel="#{item.vocabulary.label}" /> > These ways to declare selections should be made available through XML > configuration. > Syntax is still to discuss. > 2.5.2 Directorywidget types > > SelectOne and SelectMany directory widget types are using hardcoded schema > names (vocabulary, xvocabulary) which makes it very difficult to adapt when > work- > ing with other schemas. Also, only two of the previously presented six > available se- > lectors have been defined to work with directories. > Only the usage of the "nxdir:selectItems" tag combined with standard select > com- > ponents makes it possible to define such selections. > However, these components offer features that are currently not supported by > gen - > eric selection items: > - read only mode, to be able to reuse the same component features in view mode > (displayValueOnly), with separator in case it is > multi-valued > (displayValueOnlySeparator) > - automatic translation of labels > Some other features are supported but may require additionnal configuration, > like > displaying the disabled selection item stating "please select a value". > For better code maintenance, these components could be mapped to facelet > handlers that would generate the needed sub-components when calling only one > dedicated tag with the appropriate attributes. > Other similar components (selectOneRadio, selectManyCheckbox) could be added > easily following the same principle. > Chain select components would also benefit from this kind of refactoring: > their > implementation is blurry, buggy, and their behaviour can easily be done using > the > above directory selectors, combined with ajax calls to restrict values from a > second > selector, or add some selections to a list. > One of the features to expect is to be able to configure a n-level chain > select just by > giving attributes like : directoryLevel1 = directoryLevel2= directoryLevel3= > , ... > TODO: make a detailed list of chain select features before deciding how it > should be rewritten or repackaged. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ ECM-tickets mailing list ECM-tickets@lists.nuxeo.com http://lists.nuxeo.com/mailman/listinfo/ecm-tickets