> 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.Mathias, I found what you are looking for: >From the tag documentation on tr:table, attribute var: "Name of the EL variable used to reference each element of this collection. Once this component has completed rendering, this variable is removed (or reverted back to its previous value)." Quite clearly, it documents that the trinidad table should revert the var back to its previous value. I have a feeling you have found an instance where it may not be. I was going under the incorrect assumption that the trinidad table was comparable to the h:dataTable which does not support re-use of the var in nested tables. Really sorry for my mistakes in (1) misunderstanding that c:set in facelets is different in its behavior from c:set in JSTL and (2) that Trinidad's table var is different from the JSF core table. As for a test case, it seems like your nested example should work without needing facelets possibly. -Andrew
