myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Delbecq <>
Subject Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Date Tue, 12 Jun 2007 17:42:20 GMT
I agree with you, component values should be set by their renderer and
the component having isRendered() to false (along with their childs)
should not be part of validation process.

Concerning the tabbedpane, it's just a laying-out component, showing one
part of the form at a time. But, at all moments, the tabs have
isRendered() set to true. And they are rendered! The active one with
full visible content, the inactive one resume as a button header. As
they have isRendered() to true, they should, according to JSF specs,
validate themselves and call the validation process on their immediate

The whole question is there. Should an inactive tab have isRendered()
return false or true? It currently returns true.

Now the fact component without submitted value do not validate may be a
problem, depending on the details of JSF specs.
Andrew Robinson a écrit :
> Manually setting the submitted value on components that do not have a
> submitted value really goes against JSF standards.
> The fact that doesn't throw a validation error if
> isRequired is true and getSubmittedValue() is null I think is a
> shortcoming/bug in the JSF specification (or at least in MyFaces's
> implementation), but I strongly feel against forcing the setting of
> submitted values on components, as that is the job of the renderer of
> that component (or the component itself), not parents of that
> component.
> As for not validating renderer components, as I mentioned earlier,
> that is the "way it is supposed to be". Components not rendered by the
> renderer, should not be validated. JSF validation should not replace
> backing bean validation, it should simple enhance it (that also covers
> the use case of hacking around validation by removing submitted values
> or removing elements on the client).
> On 6/12/07, David Delbecq <> wrote:
>> Hello everyone
>> I did a bit of investigations on how to force validation of all tabs,
>> including those never yet rendered. It seems blocked by a characteristic
>> of validation: Validation will be completly bypassed on most components
>> if there has never been a _submittedValue for that component. This is
>> important because that mean the user behind his web browser has the
>> possibity to completly bypass validation of required fields. If you
>> require a valid client number for a message contact form, for example,
>> user can simply remove this field from DOM tree to ignore this (Note:
>> this is different to not filling entry).
>> Note: i could bypass  without troubles validation there:
>> using this simple javascript command in url bar:
>> javascript:document.getElementById('form1').removeChild(document.getElementById('form1:number1'))
>> Is it expected feature of validation or a bug in myface?
>> If it's expected behaviour, then to ensure all tabs get validated we
>> could
>> during decode of panel, scan tree below each non active tab, (stopping
>> at !isRendered() components to respect specs)
>> for each EditableValueHolder which does not have yet a submitted value,
>> set the submited value to the converted value of model (this is like
>> doing a encode/decode but all server side).
>> wrote:
>> Hi,
>>  submitted patch wouldn't break old apps (it has default of NOT
>> validating not-selected tabs).
>> But it has limitation:
>> it can validate only so far visited/rendered tabs (and only
>> visited/rendered subcomponents)
>> Limitation comes from the way TabbedPane is rendered:
>> it renders only active tab in server-side tabbing (lines 552-555 in
>> HtmlTabbedPaneRenderer).
>> This seems to be chosen for being less evil than messing with rendered
>> attribute in all tabs after change of selected tab [should be consulted
>> with original commiter].
>> Is there any method in MyFaces allowing to create component tree w/o
>> actually rendering it?
>> This would allow this kind of validation. (I fear that would require to
>> alter way rendering is functioning - decoupling rendering into creating
>> tree and actual rendering).
>> With regards,
>> Zdenek

View raw message