[
https://jira.nuxeo.com/browse/NXP-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=110259#comment-110259
]
Olivier Grisel commented on NXP-4935:
-------------------------------------
Additional use case:
Have a generic suggestbox widget that can use the SuggestionService as a
backend and the suggestersGroup id as a property of the widget so as to be able
to generate values that come from the the core, the directories, a remote
service such as a Stanbol server or a mix of all of those.
> 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: 6.0
>
>
> 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
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
