[
https://issues.apache.org/jira/browse/TOBAGO-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488012
]
Guido Dubois commented on TOBAGO-322:
-
Are you still working at this problem? Other question: How long it will
Overlay panel should removed when ajax request fails
Key: TOBAGO-350
URL: https://issues.apache.org/jira/browse/TOBAGO-350
Project: MyFaces Tobago
Issue Type: Bug
Reporter:
Overlay panel renders on wrong position
---
Key: TOBAGO-351
URL: https://issues.apache.org/jira/browse/TOBAGO-351
Project: MyFaces Tobago
Issue Type: Bug
Reporter: Volker Weber
tc:sheet need preserveDataModel
---
Key: TOBAGO-352
URL: https://issues.apache.org/jira/browse/TOBAGO-352
Project: MyFaces Tobago
Issue Type: Improvement
Components: Core
Affects Versions: 1.0.11
[
https://issues.apache.org/jira/browse/TOBAGO-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Weber resolved TOBAGO-351.
-
Resolution: Fixed
Overlay panel renders on wrong position
partial rendering support for the new tree
--
Key: TOBAGO-353
URL: https://issues.apache.org/jira/browse/TOBAGO-353
Project: MyFaces Tobago
Issue Type: New Feature
Components: Core
[
https://issues.apache.org/jira/browse/MYFACES-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488114
]
Mike Kienenberger commented on MYFACES-1109:
I just tested this with subForm and t:dataTable. I
Deleting a row when t:dataList/t:dataTable preserveRowStates=true assigns
submitted values to wrong row
---
Key: TOMAHAWK-961
URL:
[
https://issues.apache.org/jira/browse/TOBAGO-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488165
]
Bernd Bohmann commented on TOBAGO-322:
--
Just added a tab example to tobago-example-test.
I can't reproduce the
I'm looking into the behavior of preserveRowStates in order to try to
fix the issues with deleting a row when preserveRowStates=true.
One of the things I notice is that the key to the row state Map is the
clientid of the dataTable, which of course varies based on the row
index. Is there some
Your ideas sound good, one thing that I remember was discussed while
implementing preserveRowStates - there were some problems with nested
data-tables - you'd need to work around those problems specifically.
What would be your idea of a key based on the row-data?
regards,
Martin
On 4/11/07,
I don't think this will affect the nested datatables since we're not
changing the value, only the key, for each row-state map entry.
However, I might be misunderstanding something.
A starting point could be
private Map _rowStates = new WeakHashMap();
Then, we'd change this:
Since it appears their will be a 2nd release canidate for Tomahawk 1.1.5, I
thought
the following command to cleanup the local maven repository might be useful.
mvn dependency:purge-local-repository -Dverbose=true -DreResolve=false
-DresolutionFuzziness=version
Notes:
reResolve=false
On 4/11/07, Paul Spencer [EMAIL PROTECTED] wrote:
Since it appears their will be a 2nd release canidate for Tomahawk 1.1.5, I
thought
the following command to cleanup the local maven repository might be useful.
mvn dependency:purge-local-repository -Dverbose=true -DreResolve=false
Would not it work the attribute 'forceIdIndexFormula' ?
I use it to generate rows where the id in the dataTable is the same as
the real id in my database table.
El mié, 11-04-2007 a las 15:54 -0400, Mike Kienenberger escribió:
I'm looking into the behavior of preserveRowStates in order to try to
Josué, thanks for contributing.
Unfortunately, the problem we're hitting here doesn't have much to do
with the table id. We're dealing with the problem of input
components in table rows losing their submitted values if an
immediate=true UICommand executes, especially if that action involves
Well, this is kinda odd.
I've implemented the converter version, and it *almost* works.
Without the converter, using the standard clientId key,
public String getAsString(FacesContext context, UIComponent
component, Object value)
{
UIData
Ok. Here's why. The data for row 2 is copied to the input
components, row data 2 is deleted, then the data from the input
components (still for the original row 2) is copied back to row 2.
before invokeAction
setRowIndex(2)
copy row 2 data to input components
22:08:32.578
the question is if we shouldn't dig deeper - shouldn't for all
row-handling your special converter be used instead of the row-index?
Trinidad has something similar (row-key).
regards,
Martin
On 4/12/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Ok. Here's why. The data for row 2 is copied
Have you read Manfred's release diary? It seems he had problems with
an unresolved artifact yesterday night...
regards,
Martin
On 4/11/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 4/11/07, Paul Spencer [EMAIL PROTECTED] wrote:
Since it appears their will be a 2nd release canidate for Tomahawk
20 matches
Mail list logo
