I think this kind of highlights the problem -- depending on the implementation of the renderer (or the statement control flow inside the renderer), we have differences in whether children are rendered, and the behavior is outside of the control of the user.
I think it makes far more sense to add a renderAll=true/false (or maybe renderVisibleTabOnly=true/false) attribute than adding attributes for controlling validation.[1] The issue is that the end user has no control of the rendering, not that the end user has no control of the validation. If you can control what is rendered, you can also control what is validated. [1] I could easily agree with a proposal to use the rendered attribute of the individual tabs instead of having it controlled by the enclosing container. On 6/11/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
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 > >> > > > > > >
