[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503363
]
David Delbecq commented on TOMAHAWK-1012:
-----------------------------------------
Indeed, only current tab is rendered, and that's what i aim at, my form is far
too big and would consume too much bandwith/ browser CPU upon render time to
use client side switching, but every part of form must be validated at once
(user swithc bettween tabs and subtabs to enter various datas coming from paper
document before saving). Moreover, it's a long data entry process and using
client state saving increases risks of Session timeouts. Last but not least, as
mention on other reports, clientside switching and validation has it's issues
too. I strongly believe a complete form separated in tabs, using serverside
switching and with full validation is not a useless thing.
Several points of what Mr Zdenek Sochor states are also false (did you actually
try those assertion with the patch i provided?):
1) components with "required" are not a problem, component not currently
rendered by the tabbed pane are keeping their state on the server, especially
their value (which is not yet applied to backing bean). If i modify a field in
tab1, go to tab2 then back to tab1, all field are keeping the submitted value
as my browser last sent them. I can put a required field in tab1, go to tab2,
and then submit. With my patch, tab1 fields are validated and the required
field passes without problem because they have a value (coming from previous
tab1 editing). Only fields marked required, not having backing bean value and
not yet entered by user will fail, but this mean they are actually empty, so it
must fail in that case.
2) Tab switching using the tab switching button occurs prior to validation and
uses FacesContext.renderResponse() to stop JSF process and as such, in no way
my patch can prevent user-intended tabswitching as validation does not occur
during tab switching
On the comment of Mr Cagatay Civici:
I you fear it will break other users of tabbedpane by validating tabs they did
not expect to be validated, don't be afraid, my patch only does validation of
not rendered pane if you explicitly asked that pane to be validated along with
current pane, using the processvalidators="true" tag attribute. So old
behaviour of validating only current tab is the default.
Additionnaly, if you look at patch, in case of validation error triggering a
tab switching the tab change listener are notified of this change too, so
everything, imho, is made in a clean way.
I, additionnaly, notice, nowhere in doc (official and/or wiki) it's stated that
non rendered component do not get validated (understand my surprise when i
noticed this unexpected behaviour) and the JSF specs, i think, when speaking
about validation, mention the component tree, not the submitted components.
IMHO, this is natural for developer to expect it's components to be validated
during JSF livecycle. The TabbedPane looks like just a laying out component.
Moreover the server/client side tab switching should have similar behaviour,
limited by compatibility with old behaviour.
As a conclusion, i personnaly see no argument in previous comment to refuse
this patch and mark this bug as invalid. It does not break old behaviour, it's
not an heavy change (only a few lines) and adds capabilities to component.
> TabbedPane does not validate non-selected tabs in server side tab switching
> mode
> --------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1012
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1012
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Tabbed Pane
> Affects Versions: 1.1.5, 1.1.6-SNAPSHOT
> Reporter: David Delbecq
> Attachments: tabbedPaneValidator.diff
>
>
> When your form spreads accross a tabbed pane, the validators of components
> residing inside not selected tab are not validated. This is a problem because
> all form need to be validated before writting values to backing beans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
