No, I don't think that's true. It may default to the behavior of renderVisibleTabOnly=true, but that's not the same thing as allowing the end-user to control that behavior, which is what I propose.
On 6/11/07, Zdeněk Sochor <[EMAIL PROTECTED]> wrote:
Mike, your proposal of renderVisibleTabOnly=true is what currently server-side does (even if in little obscuring way). Zdenek Mike Kienenberger napsal(a): > 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 >> > >> >> > > >> > > >> > >> > >>
