tag:blogger.com,1999:blog-29717104.post3603102709311760234..comments2023-06-29T04:59:15.874-06:00Comments on Working with JSF and Facelets: c:forEach with JSF could ruin your dayAnonymoushttp://www.blogger.com/profile/12230997086550680222noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-29717104.post-49514495351613616052008-10-20T09:38:00.000-06:002008-10-20T09:38:00.000-06:00Creating a new view root, or just clearing the chi...Creating a new view root, or just clearing the children of the c:forEach "parent" will indeed "work" but you get the negative side effect of loosing all component state.Anonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-80797996891531979242008-10-20T04:57:00.000-06:002008-10-20T04:57:00.000-06:00I have noticed that while the initial rendering in...I have noticed that while the initial rendering in my case results in the wrong values rendered within the wrong iteration HTML output, subsequent renderings are correct. Based on this, I found that setting the context view root to a new one is a workaround for this.Anonymoushttps://www.blogger.com/profile/14695627311322754581noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-12691153641450919012008-10-08T09:00:00.000-06:002008-10-08T09:00:00.000-06:00@Matt: The big problem is that it isn't really a b...@Matt: The big problem is that it isn't really a bug as much as a design oversight. It just goes to show you that JSTL and JSF really are not made to be used together. As for you question on caching, it is not caching the items, but rather caching indexes on the ValueExpression instances inside of the component. Really ends up in a messy state. Best workaround is to not use JSTL.Anonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-71770286337275524012008-10-08T00:12:00.000-06:002008-10-08T00:12:00.000-06:00...one thing I don't get is why this component cac......one thing I don't get is why this component caching would be occuring when the items List is provided by a request scoped bean. Surely it should be expected that with each request the bean list property may be different (it is set on each request). I guess there is no rationale behind bugs :)Anonymoushttps://www.blogger.com/profile/14695627311322754581noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-75173285463567836362008-10-07T23:57:00.000-06:002008-10-07T23:57:00.000-06:00Glad I've found someone with the same problem....Glad I've found someone with the same problem.<BR/><BR/>I'm experiencing this now, but with adding items to a List.<BR/>My forEach simply creates an OutputText component for each iteration within an "li" element.<BR/><BR/>The weird behaviour when an item is added to the list after the initial render is that the loop iterates the correct number of times, but this happens:<BR/>1. Iterations prior to the last render nothing.<BR/>2. All additional items are rendered in the final iteration, but before the old "last" item.<BR/><BR/>So, if item C was added to a list the output would be:<BR/>[li][span>A[/span][/li]<BR/>[li] [/li]<BR/>[li][span]C[/span][span]B[/span][/li]<BR/><BR/>Pretty annoying!<BR/>I'm using JSP2.1, JSF 1.2(Sun RI with glassfish 2) and JSTL 1.2 (comes with glassfish 2).Anonymoushttps://www.blogger.com/profile/14695627311322754581noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-53898905546268994372008-08-27T11:51:00.000-06:002008-08-27T11:51:00.000-06:00I have not coded the work-around, that is why I di...I have not coded the work-around, that is why I did not post it. It would be a bit involved as it would involve new expression objects, a new custom forEach JSP tag and a bunch of testing. I don't have the time at the moment for this research as I have a bunch of other things going on. This blog is more of a notice to people than it is a fix. My hope is that the JSF team can address the issue, that is why I logged a bug against the JSTL for this (it is not approved yet so has no public bug # to post here).Anonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-6376438162264078122008-08-27T10:48:00.000-06:002008-08-27T10:48:00.000-06:00Could you elaborate the workaround a little bit mo...Could you elaborate the workaround a little bit more? Any code examples would be helpful. Thanks!Unknownhttps://www.blogger.com/profile/03015525666616446118noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-15742879446606815242008-08-11T13:10:00.000-06:002008-08-11T13:10:00.000-06:00Hi, unfortunately AFAIK there is at least one case...Hi, unfortunately AFAIK there is at least one case where looping over a dynamic list of components has no workaround: e.g. when things are included through ui:include, then c:forEach is the only solution I know of.<BR/>Besides that - the simple workaround I use to overcome the statical behavior of c:forEach is to force the re-creation of all component list whenever it changes. This can be achieved by:<BR/>- catching a parent component by binding;<BR/>- cleaning its children list.<BR/>This way Facelets recreates the component list (along the "apply" iteration), asking the bean for the current list and all up-to-date ids.<BR/>Hope it helps.Unknownhttps://www.blogger.com/profile/11231761193177228215noreply@blogger.com