for renderers. But according to
BalusC, the spec does not mention the check on {{UIColumn}} for
{{{}invokeOnComponent{}}}. So this could be fixed without a spec change.
> UIData#invokeOnComponent does not find components
> -
>
>
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848222#comment-17848222
]
Melloware commented on MYFACES-4667:
Oh good point it might be!
> UIData#invokeOnComponent d
/issues/1905
> UIData#invokeOnComponent does not find components
> -
>
> Key: MYFACES-4667
> URL: https://issues.apache.org/jira/browse/MYFACES-4667
> Project: MyFaces Core
>
> UIData#invokeOnComponent does not find components
> -
>
> Key: MYFACES-4667
> URL: https://issues.apache.org/jira/browse/MYFACES-4667
> Project: MyFaces Core
> Issue T
SteGr created MYFACES-4667:
--
Summary: UIData#invokeOnComponent does not find components
Key: MYFACES-4667
URL: https://issues.apache.org/jira/browse/MYFACES-4667
Project: MyFaces Core
Issue Type
tandraschko merged PR #554:
URL: https://github.com/apache/myfaces/pull/554
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
[
https://issues.apache.org/jira/browse/MYFACES-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Nicolucci resolved MYFACES-4452.
-
Resolution: Fixed
> UIData has a protected non spec defined method - ne
Paul Nicolucci created MYFACES-4452:
---
Summary: UIData has a protected non spec defined method - needs to
be private
Key: MYFACES-4452
URL: https://issues.apache.org/jira/browse/MYFACES-4452
Project
createOutputLabelMap() to also add map entries for every iterated
component id inside of a UIData component by using root.visitTree() in addition
to the existing code which iterates over the root children list recursively.
Changed msgDetail and msgSummary to replace by the current clientId in addition
Mike Kienenberger created TOMAHAWK-1689:
---
Summary: t:messages replaceIdWithLabel fails for components inside
UIData elements.
Key: TOMAHAWK-1689
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1689
2.1.19
2.0.25
2.0.25-SNAPSHOT
> pushComponentToEL should be called before isVisitable is called in visitTree
> of UIData, UIForm, UINamingContainer and UI
unk
> pushComponentToEL should be called before isVisitable is called in visitTree
> of UIData, UIForm, UINamingContainer and UIRepeat
> --
>
>
ore isVisitable is called in visitTree
> of UIData, UIForm, UINamingContainer and UIRepeat
> --
>
> Key: MYFACES-4128
> URL: https://issu
Bernd Bohmann created MYFACES-4128:
--
Summary: pushComponentToEL should be called before isVisitable is
called in visitTree of UIData, UIForm, UINamingContainer and UIRepeat
Key: MYFACES-4128
URL: https
Add custom type support in UIData and UIRepeat
> --
>
> Key: MYFACES-4091
> URL: https://issues.apache.org/jira/browse/MYFACES-4091
> Project: MyFaces Core
> Issue Type: New Feature
>
Add Iterable support in UIData and UIRepeat
> ---
>
> Key: MYFACES-4089
> URL: https://issues.apache.org/jira/browse/MYFACES-4089
> Project: MyFaces Core
> Issue Type: New Feature
>
Add Map support in UIData and UIRepeat
> --
>
> Key: MYFACES-4090
> URL: https://issues.apache.org/jira/browse/MYFACES-4090
> Project: MyFaces Core
> Issue Type: New Feature
>
Thomas Andraschko created MYFACES-4091:
--
Summary: Add custom type support in UIData and UIRepeat
Key: MYFACES-4091
URL: https://issues.apache.org/jira/browse/MYFACES-4091
Project: MyFaces Core
Thomas Andraschko created MYFACES-4090:
--
Summary: Add Map support in UIData and UIRepeat
Key: MYFACES-4090
URL: https://issues.apache.org/jira/browse/MYFACES-4090
Project: MyFaces Core
Thomas Andraschko created MYFACES-4089:
--
Summary: Add Iterable support in UIData and UIRepeat
Key: MYFACES-4089
URL: https://issues.apache.org/jira/browse/MYFACES-4089
Project: MyFaces Core
, but I don't know if that
could help in your case.
MyFaces PSS algorithm aim to apply PSS inclusive in sections where ui:include
src=EL expr is used. Mojarra does not have those optimisations. I ignore what's
inside primefaces, but I'm aware there is a copy of Mojarra UIData deep inside
its sources
my point of view, problem is in ComponentTagHandlerDelegate - myfaces
>calls markInitialState during apply method, Mojarra does not.
Thanks for doing deeper investigation about this problem.
Jiri
> MyFaces + Primefaces: Dynamic ui:include + UIData (with rowStatePreserved)
> rende
. According to the tests,
the exception does not happen inside MyFaces, and it is related to primefaces
p:dataGrid component, which overrides UIData. There is nothing to do in that
case from myfaces perspective, because the fix should be done in primefaces.
I'll close this issue as invalid
Jiri Slovak created MYFACES-4074:
Summary: MyFaces + Primefaces: Dynamic ui:include + UIData (with
rowStatePreserved) rendering problem
Key: MYFACES-4074
URL: https://issues.apache.org/jira/browse/MYFACES-4074
committed the patch that adds _rowStates and do other fixes, to ensure
saveState/restoreState works if they are called at the end of invoke
application phase and before render response phase.
> UIData state is not restorable when rowStatePreserved is set to t
[
https://issues.apache.org/jira/browse/MYFACES-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15303360#comment-15303360
]
Leonardo Uribe commented on MYFACES-4036:
-
Created issue MYFACES-4048
> UIData st
d be saved with the component state
too.
This behavior was not originally thought (because in the JSF EG we never went
that far to consider portlets) but it has a lot of sense, and in the "spirit"
to make things just work, I think we need a new issue for this behavior t
nformation in the state. On the next postback request,
this map is filled on apply request value phase, but again, it has a transient
nature.
According to the spec, the current behavior of UIData is correct, but on
portlet case the idea is we can apply saveState safely at the end of invoke
applica
have realized there is
something wrong in the current UIData implementation.
The problem is call saveState(...) and restoreState(...) at the end on invoke
application phase could lead to inconsistencies. The reason is there is some
information in _rowStates that is not saved with the state, so
.
Also processViewstate returns an object but buildView is a void method . Can
you please suggest how can we get the viewstate after JSF lifecycle is executed
. Please share your thoughts .
> UIData state is not restorable when rowStatePreserved is set to t
() is called, and
that code should be called every time the initial state is built or calculated.
> UIData state is not restorable when rowStatePreserved is set to true
>
>
> Key:
Hank Ibell created MYFACES-4036:
---
Summary: UIData state is not restorable when rowStatePreserved is
set to true
Key: MYFACES-4036
URL: https://issues.apache.org/jira/browse/MYFACES-4036
Project
cannot because we have to support JSF
1.2 with the component. Anyway thanks for the patch, I will integrate it into
the sandbox component.
focus cannot locate targets inside UIData elements
--
Key: TOMAHAWK-1607
for the fix
focus cannot locate targets inside UIData elements
--
Key: TOMAHAWK-1607
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1607
Project: MyFaces Tomahawk
Issue
: Resolved (was: Patch Available)
Refactor UIRepeat code to implement PSS algorithm like UIData and fix state
behavior
Key: MYFACES-3463
URL: https://issues.apache.org
algorithm like UIData and fix state
behavior
Key: MYFACES-3463
URL: https://issues.apache.org/jira/browse/MYFACES-3463
Project: MyFaces Core
Issue Type
a patch, taking what's necessary from UIData.
At the end the code has two differences:
- State for rows (rowState) was saved into the state. This is not necessary
because the information for EditableValueHolder is usually send to the client
and then go back to the server. UIData do
:
public boolean isRendered(Object row) {
if (row != null) {
// evaluate rendered with not null row
}
return [false|true];
}
Improve DebugPhaseListener for UIData and SKIP_ITERATION
[
https://issues.apache.org/jira/browse/MYFACES-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kočí resolved MYFACES-3033.
--
Resolution: Won't Fix
Improve DebugPhaseListener for UIData and SKIP_ITERATION
Refactor UIRepeat code to implement PSS algorithm like UIData and fix state
behavior
Key: MYFACES-3463
URL: https://issues.apache.org/jira/browse/MYFACES-3463
UIData in an inconsistent state causing unexpected
issues. New version resets rowIndex and uses UIComponentPerspective to
represent state.
focus cannot locate targets inside UIData elements
--
Key: TOMAHAWK-1607
focus cannot locate targets inside UIData elements
--
Key: TOMAHAWK-1607
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1607
Project: MyFaces Tomahawk
Issue Type: Bug
Components
the spec and found no mention of displaying the submitted
value if it is still set in render response (which apparently is done).
So what do you think: Is this a valid issue?
UIData does not preserve submitted values on immediate requests
).
So what do you think: Is this a valid issue?
UIData does not preserve submitted values on immediate requests
---
Key: MYFACES-3326
URL: https://issues.apache.org/jira/browse/MYFACES-3326
the reasons why Mojarra code works, but I believe that is not
intentional. In JSF 2.1, full row component state was added to UIData, and the
same principle applies, but in that case the restriction applies to all
components. Note transient component are ignored too.
The problem is adding a non
UIData performance improvements
---
Key: MYFACES-3236
URL: https://issues.apache.org/jira/browse/MYFACES-3236
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions
[
https://issues.apache.org/jira/browse/MYFACES-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3236.
-
Resolution: Fixed
Fix Version/s: 2.1.2
2.0.8
UIData
Available)
Committed solution and integrated with test patches provided. Thanks to Martin
Koci for provide this patch
2.1: implement VisitHint.SKIP_ITERATION support in UIData
-
Key: MYFACES-3025
URL: https
[
https://issues.apache.org/jira/browse/MYFACES-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2616.
-
Resolution: Fixed
Fix UIData state saving model (spec issue 153
the
row and the component state.
UIInputs in DataTable (UIData) lose submitted values when UICommands are set
to immediate=true
--
Key: TOMAHAWK-1568
URL: https
to safely evaluate EL.
Improve DebugPhaseListener for UIData and SKIP_ITERATION
Key: MYFACES-3033
URL: https://issues.apache.org/jira/browse/MYFACES-3033
Project: MyFaces Core
Issue
Improve DebugPhaseListener for UIData and SKIP_ITERATION
Key: MYFACES-3033
URL: https://issues.apache.org/jira/browse/MYFACES-3033
Project: MyFaces Core
Issue Type: Improvement
DebugPhaseListener for UIData and SKIP_ITERATION
Key: MYFACES-3033
URL: https://issues.apache.org/jira/browse/MYFACES-3033
Project: MyFaces Core
Issue Type: Improvement
Components: General
2.1: implement VisitHint.SKIP_ITERATION support in UIData
-
Key: MYFACES-3025
URL: https://issues.apache.org/jira/browse/MYFACES-3025
Project: MyFaces Core
Issue Type: Task
in UIData
-
Key: MYFACES-3025
URL: https://issues.apache.org/jira/browse/MYFACES-3025
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.1.0
or decide to make the current trunk
2.1.0-SNAPSHOT before committing this patch! feel free to start a thread about
this on the dev@ list, Martin!
2.1: implement VisitHint.SKIP_ITERATION support in UIData
-
Key: MYFACES
Validation problems with UIData from Sun RI 1.1_02
--
Key: TOBAGO-931
URL: https://issues.apache.org/jira/browse/TOBAGO-931
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
it please add this to your faces-config.xml
component
display-nameUIData/display-name
component-typeorg.apache.myfaces.tobago.Data/component-type
component-classorg.apache.myfaces.tobago.component.UIDataFixTobago931/component-class
/component
Validation problems with UIData from Sun
Resolution: Fixed
fix + test case in place
UIData: push and pop row component to and from EL during broadcast()
Key: MYFACES-2886
URL: https://issues.apache.org/jira/browse/MYFACES-2886
UIData: push and pop row component to and from EL during broadcast()
Key: MYFACES-2886
URL: https://issues.apache.org/jira/browse/MYFACES-2886
Project: MyFaces Core
Issue
[
https://issues.apache.org/jira/browse/MYFACES-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kočí updated MYFACES-2886:
-
Status: Patch Available (was: Open)
UIData: push and pop row component to and from EL during
for markInitialState() and some way to
indicate we are calling this method from the specified location.
The option (b) consider that PostAddToViewEvent should not be used to
relocate components. If components are relocated, the destiny should be outside
a UIData instance (h:outputScript
is necessary?
best regards,
Martin
Fix UIData state saving model (spec issue 153)
--
Key: MYFACES-2616
URL: https://issues.apache.org/jira/browse/MYFACES-2616
Project: MyFaces Core
Issue Type: Task
() ).
It could be good to have all calls to markInitialState() in just one place, in
one specific moment, and identify when this call comes from vld.buildView or
from UIData.setRowIndex() (we need only to save the full state if the call
comes from vdl.buildView).
Fix UIData state saving model (spec
Fix UIData state saving model (spec issue 153)
--
Key: MYFACES-2616
URL: https://issues.apache.org/jira/browse/MYFACES-2616
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
properties as suggested by Alexander
Smirnov. The idea is create an interface that allows to save/restore transient
properties like UIForm.submitted, to be saved per row. In that way, the state
could be fully restored and saved for each component.
Fix UIData state saving model (spec issue 153
Status: Resolved (was: Patch Available)
Thanks to Jakob Korherr for provide this patch
'invokeOnComponent' method in UIData does not properly process h:column
header/footer facets
turnaround guys. Look forward to trying it.
'invokeOnComponent' method in UIData does not properly process h:column
header/footer facets
--
Key: MYFACES-2370
URL
'invokeOnComponent' method in UIData does not properly process h:column
header/footer facets
--
Key: MYFACES-2370
URL: https://issues.apache.org/jira/browse/MYFACES-2370
if we solve this one and some problem happens
on next release, we could skip this one.
'invokeOnComponent' method in UIData does not properly process h:column
header/footer facets
of UIData.visitTree(). That algorithm visit child components per row. But
UIData use the same component per each row and only save the values related
to EditableValueHolder interface. The result is that we call
PostRestoreStateEvent as many times as rows are available. This behavior
Hi,
I've been working on getting the full suite of Tomahawk examples
working on the 2.0 branch. Most of the examples are working, and one
that's currently failing is Data Scroller (dataScroller.jsp). It
looks like the dataScroller bean
(org.apache.myfaces.examples.listexample.DataScrollerList)
So, how should this be approached? Fix DataScrollerList or change
UIData.getRows() to be more tolerant (i.e., cast the result to Number
and call .intValue())?
.intValue() would be fine w/ me. TCK should be fine with that as well,
I guess...
Thanks,
Curtiss Howard
--
Matthias
On Tue, Jul 21, 2009 at 8:12 AM, Matthias Wessendorfmat...@apache.org wrote:
So, how should this be approached? Fix DataScrollerList or change
UIData.getRows() to be more tolerant (i.e., cast the result to Number
and call .intValue())?
.intValue() would be fine w/ me. TCK should be fine with
On Tue, Jul 21, 2009 at 2:17 PM, Curtiss Howardcurtiss.how...@gmail.com wrote:
On Tue, Jul 21, 2009 at 8:12 AM, Matthias Wessendorfmat...@apache.org wrote:
So, how should this be approached? Fix DataScrollerList or change
UIData.getRows() to be more tolerant (i.e., cast the result to Number
yes, true. I switched my mind. I don't see any reason for long as well.
Guess I should have checked JIRA first... looks like this issue _has_
been known about for two years ;)
https://issues.apache.org/jira/browse/TOMAHAWK-1064
Curtiss Howard
[
https://issues.apache.org/jira/browse/MFCOMMONS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Demarty updated MFCOMMONS-2:
---
Status: Patch Available (was: Open)
ExporterActionListener should be dependant of UIData
ExporterActionListener should be dependant of UIData instead of HtmlDataTable
-
Key: MFCOMMONS-2
URL: https://issues.apache.org/jira/browse/MFCOMMONS-2
Project: MyFaces
(was: Patch Available)
Patch applied. Thanks Bogdan. Please note that patches are usually applied
sooner if they are SVN diffs.
UIColumns component must be a child of a UIData component
--
Key: TOMAHAWK-1156
URL
will be in sync
and the application is also in control of when to reset it. Moreover the data
scroller does not need the UIData hence for attribute is not needed.
ex:
t:datatable first=#searchPageBean.startRowIndex ...
...
/t:datatable
t:dataScroller startRowIndex=#searchPageBean.startRowIndex
the UIData hence for attribute is not needed.
ex:
t:datatable first=#searchPageBean.startRowIndex ...
...
/t:datatable
t:dataScroller startRowIndex=#searchPageBean.startRowIndex ...
...
/t:dataScroller
in searchPageBean's search method the attribute startRowIndex can be set to 0
when
:
-
Since UIData supports value binding for the attribute first (getFirst is
using it), Can we have setFirst push it to the valuebinding (if the
valuebinding is present)?
In the current implementation setFirst only stores it locally thus makes the
value binding useless.
By making
:
-
Since UIData supports value binding for the attribute first (getFirst is
using it), Can we have setFirst push it to the valuebinding (if the
valuebinding is present)?
In the current implementation setFirst only stores it locally thus makes the
value binding useless.
By making
:
-
Since UIData supports value binding for the attribute first (getFirst is
using it), Can we have setFirst push it to the valuebinding (if the
valuebinding is present)?
In the current implementation setFirst only stores it locally thus makes the
value binding useless.
By making
:
-
Since UIData supports value binding for the attribute first (getFirst is
using it), Can we have setFirst push it to the valuebinding (if the
valuebinding is present)?
In the current implementation setFirst only stores it locally thus makes the
value binding useless.
By making
[
https://issues.apache.org/jira/browse/TOMAHAWK-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577581#action_12577581
]
Phanidhar Adusumilli commented on TOMAHAWK-548:
---
Since UIData supports
DataModel in
UIData
---
Key: MYFACES-1225
URL: https://issues.apache.org/jira/browse/MYFACES-1225
Project: MyFaces Core
Issue Type: Improvement
Components
sources trunk -- private. Checked out
branches/1_2_2 --- no UIData at all... It seems I completely misunderstand
MyFaces SVN. Is https://svn.apache.org/repos/asf/myfaces/core/trunk a valid
URL for trunk at all?
JSR-252 Issue #58: Enabled protected access to internal DataModel in
UIData
-generation is done is that JSP taglibs,
faces-config files, facelets config files, etc all need to be consistent. In
the old code this was done by hand, and many errors resulted.
You will find the new UIData here, as a template that is modified during
build:
https://svn.apache.org/repos/asf
are possible without major code duplication as with
1.1.
JSR-252 Issue #58: Enabled protected access to internal DataModel in
UIData
---
Key: MYFACES-1225
URL: https
and is private in SVN. What has changed?
I stumbled into it after I derived right from UIData: cannot play around with
createDataModel, while I could with a custom Tomahawk table derivative.
Apparently, Tomahawk uses some hack class. And Tomahawk's wish to have
access to getDataModel() etc
*/
UIComponent parent = getParentUIData().getParent();
...
}
UIColumns component must be a child of a UIData component
--
Key: TOMAHAWK-1156
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1156
of a UIData component
--
Key: TOMAHAWK-1156
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1156
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Columns
Affects
. If not is there a
timeline by
when this will be fixed.
Thanks,
Raghu
UIColumns component must be a child of a UIData component
--
Key: TOMAHAWK-1156
URL: https://issues.apache.org/jira/browse/TOMAHAWK
UIData do not honor first and row value binding in decode
-
Key: MYFACES-1789
URL: https://issues.apache.org/jira/browse/MYFACES-1789
Project: MyFaces Core
Issue Type: Bug
Version for
now.
UIData do not honor first and row value binding in decode
-
Key: MYFACES-1789
URL: https://issues.apache.org/jira/browse/MYFACES-1789
Project: MyFaces Core
Issue
[
https://issues.apache.org/jira/browse/TOMAHAWK-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramy Siha updated TOMAHAWK-1156:
Status: Patch Available (was: Open)
UIColumns component must be a child of a UIData component
UIColumns component must be a child of a UIData component
--
Key: TOMAHAWK-1156
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1156
Project: MyFaces Tomahawk
Issue Type: Bug
invokeOnComponent returns wrong reference for UIData children
-
Key: MYFACES-1738
URL: https://issues.apache.org/jira/browse/MYFACES-1738
Project: MyFaces Core
Issue Type: Bug
[
https://issues.apache.org/jira/browse/MYFACES-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531596
]
Leonardo Uribe commented on MYFACES-1738:
-
It's not a bug. UIData use the same components to render each
1 - 100 of 201 matches
Mail list logo
