You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Paul Spencer <pa...@apache.org> on 2007/06/11 16:35:59 UTC
TabbedPane does not validate non-selected tabs in server side tab
switching mode (Relaed to TOMAHAWK-1012)
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
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Mike Kienenberger <mk...@gmail.com>.
That could be one way to do it, although I think there may be issues
with doing it that way -- you might end up with needing to nest forms,
which cannot be done.
I'd be doing something like this instead:
<h:form>
<t:documentBody>
<t:panelTabbedPane>
<t:panelTab label="Query by Date">
<sandbox:subForm>
...
<h:inputText value="#{startTime}" required="true"/>
...
</sandbox:subForm>
</t:panelTab>
<t:panelTab label="Query by SKU">
<sandbox:subForm>
...
<h:inputText value="#{sku}" required="true"/>
...
</sandbox:subForm>
</t:panelTab>
</t:panelTabbedPane>
</t:documentBody>
</h:form>
There are probably some other details you'll have to work out,
depending on the location of your submit button relative to the
subform.
On 6/11/07, Paul Spencer <pa...@apache.org> wrote:
> Mike,
> In my query example, each tab contains a form, see below. Is this what
> you are talking about?
>
> <t:documentBody>
> <t:panelTabbedPane>
> <t:panelTab label="Query by Date">
> <f:form>
> ...
> <h:inputText value="#{startTime}" required="true"/>
> ...
> </f:form>
> </t:panelTab>
> <t:panelTab label="Query by SKU">
> <f:form>
> ...
> <h:inputText value="#{sku}" required="true"/>
> ...
> </f:form>
> </t:panelTab>
> </t:panelTabbedPane>
> </t:documentBody>
>
> Paul Spencer
>
>
> Mike Kienenberger wrote:
> > 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 <pa...@apache.org> 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
> >>
> >
>
>
Re: TabbedPane does not validate non-selected tabs in server side
tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Paul Spencer <pa...@apache.org>.
Mike,
In my query example, each tab contains a form, see below. Is this what
you are talking about?
<t:documentBody>
<t:panelTabbedPane>
<t:panelTab label="Query by Date">
<f:form>
...
<h:inputText value="#{startTime}" required="true"/>
...
</f:form>
</t:panelTab>
<t:panelTab label="Query by SKU">
<f:form>
...
<h:inputText value="#{sku}" required="true"/>
...
</f:form>
</t:panelTab>
</t:panelTabbedPane>
</t:documentBody>
Paul Spencer
Mike Kienenberger wrote:
> 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 <pa...@apache.org> 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
>>
>
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <zd...@ataco.cz> 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 <an...@gmail.com> 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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
> >> > >>
> >> > >
> >> > >
> >> >
> >> >
> >>
>
>
>
Re: TabbedPane does not validate non-selected tabs in server side
tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Zdeněk Sochor <zd...@ataco.cz>.
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 <an...@gmail.com> 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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
>> > >>
>> > >
>> > >
>> >
>> >
>>
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <an...@gmail.com> 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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
> > >>
> > >
> > >
> >
> >
>
Re: TabbedPane does not validate non-selected tabs in server side
tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Zdeněk Sochor <zd...@ataco.cz>.
Hi,
comments inline.
Andrew Robinson napsal(a):
> 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.
By trying patch i noticed unvisited tabs' content is NOT in component
tree (i had required fields in all tabs).
They simply weren't added due to not rendering their respective tab.
After switching tabs all fields in visited tabs get validated (being
added to component tree during their rendering).
> As for the rendered,
> I was not referring to the rendered attribute, but the rendered state.
JSf spec is not clear with distinction of these two :(
> 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.
>
The very point of discussion ;)
> 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.
>
That depends on purpose of tabbedPane - if it's related to only 1 object
with splitted properties through tabs,
it would be useful to get all valid properties from all tabs.
Zdenek
> On 6/11/07, Zdeněk Sochor <zd...@ataco.cz> 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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>>
>>
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Andrew Robinson <an...@gmail.com>.
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 <zd...@ataco.cz> 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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
> >> >>
> >> >
> >> >
> >>
> >>
>
>
Re: TabbedPane does not validate non-selected tabs in server side
tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Zdeněk Sochor <zd...@ataco.cz>.
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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
>> >>
>> >
>> >
>>
>>
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Andrew Robinson <an...@gmail.com>.
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 <zd...@ataco.cz> 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 <pa...@apache.org> 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
> >>
> >
> >
>
>
Re: TabbedPane does not validate non-selected tabs in server side
tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Zdeněk Sochor <zd...@ataco.cz>.
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 <pa...@apache.org> 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
>>
>
>
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <pa...@apache.org> 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
>