Hi,
We have a web project developed using JSF 1.1 and the first version of
Oracle ADF since 2005. We are working on a migration process to a new
version of a JSF framework, and we already started replacing some ADF
components by some My Faces ones (use tomahawk datatable instead of ADF
table). As
We have a web project developed using JSF 1.1 and the first version of
Oracle ADF since 2005. We are working on a migration process to a new
version of a JSF framework, and we already started replacing some ADF
components by some My Faces ones (use tomahawk datatable instead of ADF
table). As
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503331
]
Zdenek Sochor commented on TOMAHAWK-1012:
-
Hi,
this issue is IMHO invalid due to intended use of
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503332
]
Cagatay Civici edited comment on TOMAHAWK-1012 at 6/11/07 1:50 AM:
---
If we
Move autoscroll feature from shared HtmlRendererUtils to Tomahawk
-
Key: MYFACES-1662
URL: https://issues.apache.org/jira/browse/MYFACES-1662
Project: MyFaces Core
Issue Type:
Sheets disappear on a tab in IE
---
Key: TOBAGO-419
URL: https://issues.apache.org/jira/browse/TOBAGO-419
Project: MyFaces Tobago
Issue Type: Bug
Components: Themes
Affects Versions: 1.0.11
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503379
]
Zdenek Sochor commented on TOMAHAWK-1012:
-
Hi,
I played with the patch and my notes:
1. required
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503381
]
Zdenek Sochor commented on TOMAHAWK-1012:
-
And little side note:
taken from specification's api
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503386
]
David Delbecq commented on TOMAHAWK-1012:
-
Hi, first thanks for pointing out problem with children of tab
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503390
]
Zdenek Sochor commented on TOMAHAWK-1012:
-
Hi,
this should be last comment in JIRA - we should move
+1
On 6/10/07, Gerald Müllan [EMAIL PROTECTED] wrote:
+1
On 6/9/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
I was running the needed tasks to get the 101 release of the Trinidad
MyFaces Plugins out. This is the first release since leaving the
Apache Incubator.
The artifacts are
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
[
https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503421
]
Paul Spencer commented on TOMAHAWK-1012:
I have add a thread to the dev list titled TabbedPane does not
On 6/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
We have a web project developed using JSF 1.1 and the first version of
Oracle ADF since 2005. We are working on a migration process to a new
version of a JSF framework, and we already started replacing some ADF
components by some My
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
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
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
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
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
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
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
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
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
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
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
Moving this to Dev list since it belongs there... :)
Martin Marinschek wrote:
Hi Scott,
interesting, thanks for the further clarification. I see the problems
very clearly now. Well then - let's start off this portlet bridge, and
see where it brings us to!
regards,
Martin
On 6/11/07, Scott
Hey Martin,
One thing we could look at if 286 won't be released for a while is an
extension to Trinidad to support a plugable ppr system. This would be
a lot of work but we could have plugins for various portals that would
allow us to enable PPR. If a plugin was not available for a
27 matches
Mail list logo
