[
https://jira.nuxeo.org/browse/NXP-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anahide Tchertchian updated NXP-4930:
-------------------------------------
Description:
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
> Package more widgets
> --------------------
>
> Key: NXP-4930
> URL: https://jira.nuxeo.org/browse/NXP-4930
> Project: Nuxeo Enterprise Platform
> Issue Type: Sub-task
> 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
