Sorry for my confusion. Why is it weird that visited tabs are in the component tree? The components from all tabs should always be in the tree regardless if they have been visited or not. As for the rendered, I was not referring to the rendered attribute, but the rendered state. The tabs, I would think, are much like tree nodes. When a tree node is not expanded, the non-visible nodes are not validated or updated, only the expanded, visible nodes. So to me it would make sense on only validate/update the components of the visible/selected tab.
Basically, if the components were rendered, they should be decoded, validated and updated. Since the non-selected tabs are not rendered (by the renderer) in server switch mode, then on post back they should not be decoded, validated or updated. This should cause bugs in code since there are no submitted values for the EditableValueHolder components of tabs not rendered by the renderer. On 6/11/07, Zdeněk Sochor <[EMAIL PROTECTED]> wrote:
Andrew, the question was not about bypassing validation of currently shown tab, but about validation of not-rendered tabs ALONG with current tab's content. From rigid point of view, all tabs could be defined as rendered=true (and should be validated), BUT renderer in server-side tabbing actually renders ONLY active tab (and therefore validates only active tab's content). Weirdly enough, all previously visited tabs ARE in component tree after switching tabs. Zdenek Andrew Robinson napsal(a): > I would disagree with the statements made about the tab panel having > to validate all tabs or no tabs on server side submitting. Since the > contents of only one tab is rendered, the JSF standard is to validate > and update only those controls that are rendered (the current tab > displayed). For the argument that people may want to bypass the > validation & update phase when the user switches tabs -- that is > usually the functionality of an immediate flag on a component. > > My personal preference would be to have skipValidation/skipUpdates or > processValidation/processUpdates attributes on the tab panels that > would allow the user to override the default behavior and stop the > validation and updating of child components (not call > processValidators/processUpdates on the children of the currently > selected tab). > > As for client side tab switching, validation and updating has to be > done on the children of all tabs of course. > > On 6/11/07, Zdeněk Sochor <[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 >> >> Mike Kienenberger napsal(a): >> > I think someone else already pointed this out, but from an "ideal >> > design" point of view, the tabbed panes are for organizing information >> > visually, not for supporting partial validation. >> > >> > To me, the ideal design would be to have all tabbed panes validated, >> > just like for any other visual element, and then, if you needed >> > partial validation, make use of the subForm tag by enclosing each >> > tabbed pane. >> > >> > On 6/11/07, Paul Spencer <[EMAIL PROTECTED]> wrote: >> >> I use server side switching. Validation of non-selected tab would >> break >> >> many pages in my applications. As an example, one of the >> applications >> >> allows the user to query a database. Each tab is a specific type of >> >> query with it's own requirement, i.e. "Start Time" and End Time" >> fields >> >> are required on the "Query by Time" and "SKU" is required on the >> "Query >> >> by "SKU" tab. Forcing non-selected tab to pass validation would >> break >> >> this part of the application since many cases the required fields >> have >> >> no default value by design. >> >> >> >> I can see a case where validation of non-selected tabs is need. >> As an >> >> example, a series of tab that collect customer information where each >> >> tab is a type of information, "Name" "Billing Address" "Shipping >> >> Address".... Whether this should be implement as a >> >> "validateNonSelectedTab" attribute on <t:panelTabbedPane> and/or >> >> <t:panelTab> is it's own discussion. >> >> >> >> Paul Spencer >> >> >> > >> > >> >>
