Hi Andrew,
> This either should be (1) not a bug, but discussed on the
> user mailing list until the actual bug is found and not just
> reporting that your code doesn't work or (2) submit a
In fact, Matthias Weßendorf asked me to fill a bug report. See his post from
5th of July on the user mailing list.
> reproducible test case maven project to debug.
At the moment, I'm unable to create a maven test project. I've never used
maven, except for 'maven build' and don't know how to create such a project.
But I can provide the minimalistic sample (with or without jars). Would that
be okay?
> #2 would probably be best. As long as the project depends on
> maven to build and uses only jars from central and other
> public repositories, it would make testing a lot more easy.
No, it does not depend on maven.
> I meant facelets 1.1.14. There have been people reporting
> problems with 1.1.14 and variable scoping.
Do you know any related posts?
> You haven't nested the components have you?
As I wrote, I have.
> If you have nested a table with var=row in another table with
> var=row, it won't work. You cannot re-use the same var in the
> same component tree, it has to be unique. This is because the
> var is stored into the request map. When an inner table would
> write the value, it would replace any existing value.
Sure! That's what I want and _IT WORKS_ great for the first nested table,
but not for the next table nested in the first nested table.
Schema:
<tr:table value="samples" var="row">
<f:facet name="detailStamp"> <- click on details work's great
<tr:table value="#{row.findings}" var="row">
<f:facet name="detailStamp"> <- click on details
does not work with 1.2.9, but works up to 1.2.8
<tr:table value="#{row.findingData}"
var="row">
</tr:table>
</f:facet>
</tr:table>
</f:facet>
</tr:table>
All tables are created by the same facelet component.
If the var is overwritten in the request map, it can than be used again, but
not with the previous value. That is obvious.
What now happens is that the execution order may have changed, because var
is assigned to row object of the new table before the value expression
#{row.findingData} gets evaluated.
Ah no! Read the exception again:
SCHWERWIEGEND: JSF1054: (Phase ID: INVOKE_APPLICATION 5, View ID:
/general/Patient.xhtml) Exception thrown during phase execution:
[EMAIL PROTECTED]
6237]
18:57:21,423 ERROR [ExceptionFilter] handling uncaught exception
javax.servlet.ServletException: /WEB-INF/facelets/tags/ienestedtable.xhtml
@26,68 value="#{source}": /WEB-INF/facelets/tags/ienestedtable.xhtml @15,55
value="#{parent[value]}": Property 'findings' not found on type
entities.Finding
That means the problem is with the rerendering of the first nested table,
because entities.Finding is accessed. During this, #{parent[value]} is set
to the current row and not to the parent.
Maybe something has changed in the detailStamp PPR routines?
For the very first rendering it works, but not after clicking on details.
Maybe that's a hint.
--
Kind regards,
Mathias
