Thanks for the correction David, I should have checked the specification myself, sorry for the rabbit trail. The reason as mentioned before that validation does not take place for non-rendered components is not that it isn't called on those components, but rather there is no submitted value for components that have not been rendered.
As mentioned before, calling the validators on the hidden tabs will not usually change the behavior as UIInput components that do not have a submitted value are considered valid automatically (http://tinyurl.com/2z2mjj) since the validate function falls out if there is no submitted value. On 6/12/07, David Delbecq <[EMAIL PROTECTED]> wrote:
Maybe am badly reading the specifications?: 2.2.3 Process Validations .... During the Process Validations phase of the request processing lifecycle, the JSF implementation must call the processValidators() method of the UIViewRoot of the tree. This will normally cause the processValidators() method of each component in the tree to be called recursively, as described in the API reference for the UIComponent.processValidators() method. Note that EditableValueHolder components whose immediate property is set to true will have had their conversion and validation processing performed during Apply Request Values phase. .... From this point, we get to the way the tabbed pane must implement processValidators() to conform specifications, reading the api docs of UIComponent as the specs tells us to do: public abstract void processValidators(javax.faces.context.FacesContext context) Perform the component tree processing required by the Process Validations phase of the request processing lifecycle for all facets of this component, all children of this component, and this component itself, as follows. - If the rendered property of this UIComponent is false, skip further processing. - Call the processValidators() method of all facets and children of this UIComponent, in the order determined by a call to getFacetsAndChildren(). This clearly mention the "rendered property". Tabbed Pane must not skip further processing and must call processValidators() for all it's facets and children! Those children are mainly made of tab components. All those tabs have rendered property set to true, so they themself also must calls processValidators() on their children and facets. Now if the tabs would have their rendered property to false, they would skip validation of themselves and their content, but this is not the case. As for the getRendersChildren() you mentioned, it's unrelated. It appear twice in specs, "8.2 Renderer" and "9.2.8 Interoperability with JSP Template Text and Other Tag Libraries". Nothing suggest it has to do with processValidators() behaviour. I think you are mixing the validation and the rendering phase. Maybe i missed some parts of specs, i don't know them by heart and am far from having the inside knowledge of myfaces developpers. But am still not convinced there is a good reason to not validate the not currently active tabs. Of course backward compatibility must be preserved. Kind regards, David Delbecq Andrew Robinson a écrit : Whether a component is rendered or not is NOT based on the result of UIComponent.isRendered(), it is based on if UIComponent.isRendered() is true AND the renderer chooses to render it AND all parents of that component are rendered. The second part of that rule is just as important as the first. The litmus test, is: a component is rendered if the renderer outputs content for this component to the response writer. By this definition, the components in the non-selected tab are not rendered (it doesn't matter what the isRendered() flag is) and therefore should not be decoded, validated or updated. This is the reason why the getRendersChildren() method exists, so that renderers may choose to overwrite how the children are rendered. In fact, there is nothing in the JSF specification that I am aware of the *requires* a renderer to pay any attention to the UIComponent.isRendered() flag, especially for children components. isRendered() is more of a design pattern than a requirement (note that UIComponentBase will only call the renderer's encode method, if isRendered is true, but that doesn't mean that component will be rendered by the renderer, it only means that the encodeBegin, encodeChildren, and encodeEnd will be called on the renderer). On 6/12/07, David Delbecq <[EMAIL PROTECTED]> wrote: 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 children. 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 UIInput.java 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 <[EMAIL PROTECTED]> 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: >> http://example.irian.at/example-simple-20070612/sample1.jsf >> 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). >> >> [EMAIL PROTECTED] 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 >>
