On Tue, Jul 8, 2008 at 7:19 PM, Mathias Walter <[EMAIL PROTECTED]> wrote:
> 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.
yes, I did. :)
Since the upgrade from 128 => 129-SNAP was causing this,
I think it is valid to have this as a bug... even it is not one...
By having it in jira, we don't loose it...
(no, I haven't followed the "discussion" on the jira, though)
-M
>
>> 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
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
