[
https://jira.nuxeo.org/browse/NXP-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéfane Fermigier updated NXP-4930:
-----------------------------------
Component/s: Layouts / Widgets
> Package more widgets
> --------------------
>
> Key: NXP-4930
> URL: https://jira.nuxeo.org/browse/NXP-4930
> Project: Nuxeo Enterprise Platform
> Issue Type: Sub-task
> Components: Layouts / Widgets
> Reporter: Anahide Tchertchian
>
> 2.1 Currentexistingwidgets
>
> There is a dozen of builtin widget types, to handle common field types: text,
> int,
> secret, textarea, datetime, file, htmltext, selectOneDirectory,
> selectManyDirectory,
> checkbox, template, list.
> These "builtin" widget types are contributed to the layout service using
> extension
> points and java classes, in the layout-client module.
> Most of them are coded in JAVA, and implement the widget behaviour depending
> on
> the mode: for widget of type "text" for instance, a standard JSF component
> "h:out-
> putText" will be used in view mode, and "h:inputText" will be used in edit
> mode, ac -
> companied with a JSF component "h:message" to display conversion/validation
> er-
> rors.
> The "template" widget is a little special because it enables the use of a
> xhtml page
> to describe the widget behaviour: no JAVA code is then involved. Some
> variables are
> made available within these templates (but they are not properly documented
> yet).
> More variables could be made available to get more features already offered
> when
> writing the JAVA code.
> The "list" widget is also special because it is in fact a widget of type
> "template" de -
> signed to use an hardcoded template: "/widgets/list_widget_template.xhtml".
> So when defining new widget types, two options are available:
> - code in JAVA the widget behaviour
> - use an xhtml page and hardcode its path in a JAVA class that inherits from
> the template widget type handler.
> 2.2 Currentwidget templates
>
> There is a lot of widget templates in several nuxeo packages: even if these
> tem-
> plates are sometimes generic, they are not registered to the layout service
> exten-
> sion point. Using them requires to use a widget of type "template" and state
> in the
> widget properties the template path.
> These widgets could be easily added to the list of "builtin" available
> widgets.
> Here is the list of generic widgets:
> - complex_widget_template.xhtml (from layout-client): makes it possible to
> map a
> complex field (map-like) by defining sub-widgets for each item of the map.
> It
> could be repackaged as a template widget named "complex".
> - complex_list_item_widget_template.xhtml (from layout-client): makes it
> possible
> to map a complex field (map-like) when the field is held in a list. It is
> different
> from a simple complex widget because the mapping of sub-fields cannot be
> done exactly in the same way in both cases. It could be repackaged as a
> tem-
> plate widget named "complex_list_item".
> - list_subwidget_template.xhtml (from layout-client): makes it possible to
> map a
> sub-field of type list by defining sub-widgets for each element of the
> list (e.g
> when defining a structure involving a list of lists). It could be
> repackaged as a
> template widget named "sublist".
> It is different from the simple "list" widget handler because the first
> list widget
> will define an ajax region and an iteration variable that would get mixed
> up with
> the sublist ajax region and iteration variable: this template does not
> define a
> new ajax region, and uses a distinct iteration variable. Note that yet
> another
> template would be needed to handle a list of lists of lists, to use a
> distinct itera -
> tion variable.
> - user_password_validation_widget_template.xhtml (from webapp-base): provides
> an hidden field that performs validation over password and password
> confirma-
> tion (to check that they match). It depends on webapp-base seam components,
> so it should not be made available in layout-client, but it could be
> repackaged
> here as a template widget named "single_user_group_suggestion". It also
> provides a basic cross-validation example.
> - single_user_suggestion_widget_template.xhtml (from webapp-base): provides a
> suggestion box for a single user/group selection. It depends on webapp-base
> user management seam components, so it should not be made available in lay-
> out-client, but it could be repackaged here as a template widget named
> "single_user_group_suggestion".
> - user_suggestion_widget_template.xhtml (from webapp-base): provides a sug-
> gestion box for a list of users/group selection. It depends on webapp-base
> user
> management seam components, so it should not be made available in
> layout-cli-
> ent, but it could be repackaged here as a template widget
> named
> "user_group_suggestion".
> - user_prefixed_suggestion_widget_template.xhtml (ffrom webapp-base): sames
> as above, but provides "user:" and "group:" prefixes when selecting users
> and
> groups, which is useful when needing to identify the selection type (for
> workflow
> participants for instance). It could be repackaged as
> "prefixed_user_group_sug-
> gestion".
> Here is the list of specific widgets that could be made generic:
> - directive_widget_template.xhtml (from
> jbpm-web),
> protocol_type_widget_template.xhtml (from
> mail-web),
> moderation_type_widget_template.xhtml (from webapp) : these are select one
> menus with specific values that are not stored in a directory. They could
> be
> rewritten using a generic selection widget (see chapter 2.5)
> - duedate_widget_template.xhtml (from jbpm-web): this is a datetime widget
> with
> an additional validator. This can be expressed in the XML and does not
> require a
> template. It should be removed and the widget calling it should be
> rewritten.
> - emails_limit_widget_template.xhtml (from mail-web): this is standard text
> widget with a standard JSF validator. It could be rewritten using a
> generic way-
> of defining validators (see chapter 2.4)
> - join_list_widget_widget_template.xhtml (from mail-web) and contributors-
> widget.xhtml (from webapp): these are templates presenting a list of items
> joined with a given character, and final delimiter. This could be addressed
> providing more presentation options to the list widget in view mode (see
> chapter 2.3)
> - subjects_widget.xhtml (from webapp), coverage_widget.xhtml (from webapp),
> chain_monoselect_2levels_widget.xhtml (from studio)
> and
> chain_multiselect_2levels_widget.xhtml (from studio): these are chain
> select
> widget templates. Templates used in studio are more generic and could be
> packaged as is in ui-web, naming them "chain_monoselect_2levels" and
> "chain_multiselect_2levels", and subjects and coverage widgets rewritten
> to use
> them, but improvements to chain select may have to be considered first (see
> chapter 2.5)
> - nolabel_list_widget_template.xhtml (from
> webapp),
> studio_list_widget_template.xhtml (from studio)
> and
> files_list_widget_template.xhtml (from webapp) are all variations of the
> list
> widget presentation: sometimes label should not be displayed for each
> subwidget of the list, and sometimes input file values need to be kept
> using
> some javascript hack so that chosen file paths are not removed from the DOM
> when performing an AJAX action (add or remove a new item from the list for
> instance). This could be addressed adding more presentation options for
> the list
> widget (see chapter 2.3)
> - boolean_radio_widget_template.xhtml
> and
> integer_yes_no_widget_template.xhtml (from webapp): these are presenting
> identical screens, but the value stored is either a boolean either an
> integer.
> They could be rewritten using a generic selection widget (see chapter 2.5).
> - extended_file_widget.xhtml and extended_subfile_widget.xhtml (from webapp)
> are presenting, on top of the file, additional features (live edit, pdf
> preview and
> preview links). They depend on webapp-core features, so it should not be
> made
> available in layout-client, but it could be repackaged here as template
> widgets
> named "extended_file" and "extended_subfile".
> See
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.nuxeo.org/secure/Administrators.jspa
-
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
