tag:blogger.com,1999:blog-29717104.comments2023-06-29T04:59:15.874-06:00Working with JSF and FaceletsAnonymoushttp://www.blogger.com/profile/12230997086550680222noreply@blogger.comBlogger73125tag:blogger.com,1999:blog-29717104.post-50119461885175696712009-04-04T04:26:00.000-06:002009-04-04T04:26:00.000-06:00I am using c:forEach and c:if (condition is differ...I am using c:forEach and c:if (condition is different between two sequential requests) and have a lot of problems with duplicate id's (created from index of c:forEach).<BR/>Now I know that component tree is not part of the state, things are more clear to me.<BR/>Thanks.Unknownhttps://www.blogger.com/profile/10628940511479298930noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-42610891208511213872009-04-01T12:50:00.000-06:002009-04-01T12:50:00.000-06:00Even though it is referred to as a "restore view",...Even though it is referred to as a "restore view", it should be called "re-create view"; the component tree is re-created for every request and the state is restored back into the components themselves (components have a lifespan of one request, they are not re-used unless you are using a 3rd party component library that does this). Therefore, if the c:forEach changes, the component tree will be affected. I have seen many problems with iterators, for each loops and other such devices when the data they use is request scoped and they do not realize that that data is not there on the post back.Anonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-23917343644437807922009-04-01T02:42:00.000-06:002009-04-01T02:42:00.000-06:00Hi Andrew,You wrote:a JSF component tree should ne...Hi Andrew,<BR><BR><BR/><BR/>You wrote:<BR><BR/><B>a JSF component tree should never be altered between having its state saved and when its state is restored</B><BR><BR/>But what I don't understand is when it could be changed anyway. When you first request for a page, a component tree is created based on a page descriptor (in my case a xhtml file).The second time (postback) the component tree already exists and will be restored (not be created again).<BR/>Even when you have a c:forEach loop in your file and the number of items changed I don't see how it can effect the component tree.<BR/><BR><BR><BR/>Marcel.Unknownhttps://www.blogger.com/profile/10628940511479298930noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-21279396379977113392009-03-04T20:44:00.000-07:002009-03-04T20:44:00.000-07:00First, please use my new site at http://drewdev.bl...First, please use my new site at <A HREF="http://drewdev.blogspot.com" REL="nofollow">http://drewdev.blogspot.com</A>, I will no longer be keeping this one up to date.<BR/><BR/>If you are having problems with the EL, then you probably do not have the custom component registered correctly. In my example, you will see that I replace the value expression using my buildMethodExpression function.<BR/><BR/>If you do not correctly set up all my steps, then the ValueExpression will not be replaced with the MethodExpression.<BR/><BR/>See the CompositeControlHandler code in the blog.Anonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-87992884893201415512009-03-04T19:31:00.000-07:002009-03-04T19:31:00.000-07:00Hey Andrew. This is an excellent solution. I'm goi...Hey Andrew. This is an excellent solution. I'm going to use it in my current project. However, there's just one more piece that's not yet resolved.<BR/><BR/>my:test actionListener="#{myBean.doSomething}" <BR/><BR/>In a regular JSF control, the JSF would know that actionListener refers to a method binding and it would not search for a property called doSomething in bean myBean. However, in my:test, this is not apparent and an error is thrown because myBean doesn't have a property called doSomething. How did you fix this issue. Thanks in advance.Tauqueer Alihttps://www.blogger.com/profile/03248441466262053788noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-62769363844176770452009-01-30T01:51:00.000-07:002009-01-30T01:51:00.000-07:00thx a lot mate. This really helped us out.thx a lot mate. This really helped us out.farmerhttps://www.blogger.com/profile/03927771823062749505noreply@blogger.comtag: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-84965974067405320762008-10-17T01:51:00.000-06:002008-10-17T01:51:00.000-06:00I would appreciate the opportunity to buy you a co...I would appreciate the opportunity to buy you a couple rounds. Great post, incredibly helpful. I was trying to do some binding="" magic inside a datagrid and this helped me get there.rektidehttps://www.blogger.com/profile/03381475657715288786noreply@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-88209701942774530772008-08-13T13:40:00.000-06:002008-08-13T13:40:00.000-06:00Hi Andrew,Thanks for the hints. It's working now ...Hi Andrew,<BR/><BR/>Thanks for the hints. It's working now and seems to be a fix for our issue. This has been a good learning experience.<BR/><BR/>SteveSteve Khttps://www.blogger.com/profile/14796864015870174695noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-42090146865025989842008-08-12T16:36:00.000-06:002008-08-12T16:36:00.000-06:00@Steve - I would recommend a JSF tutorial on creat...@Steve - I would recommend a JSF tutorial on creating components.<BR/><BR/>Facelets documentation has information on creating taglib.xml files. For JSP, you need to create a tag class and a TLD file.<BR/><BR/>You can try MyFaces code (see the tomahawk demo for example), or use a demo app like faces goodies:<BR/><A HREF="http://code.google.com/p/facesgoodies/" REL="nofollow">http://code.google.com/p/facesgoodies/</A>Anonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-80521912317144469812008-08-12T15:12:00.000-06:002008-08-12T15:12:00.000-06:00Hi Andrew,This is something very similar to what I...Hi Andrew,<BR/><BR/>This is something very similar to what I've been struggling with. Thanks for the idea. But, because I'm fairly new to JSF, I've got a question about the 'my:validateAction' tag. How did you link the 'my' namespace to your UIValidationActionPhase class?Steve Khttps://www.blogger.com/profile/14796864015870174695noreply@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.comtag:blogger.com,1999:blog-29717104.post-51202630050556642962008-07-17T10:23:00.000-06:002008-07-17T10:23:00.000-06:00The best thing to do is have a look at my code on ...The best thing to do is have a look at my code on the jsf-comp web site:<BR/><BR/>http://jsf-comp.svn.sourceforge.net/viewvc/jsf-comp/trunk/aa/src/net/sf/jsfcomp/aa/tree/<BR/><BR/>I stopped using Tree2 a long time ago, and now use Trinidad instead which has better framework features.<BR/><BR/>As for portals, I have no idea if AjaxAnywhere is compatible. I know that Trinidad is fairly portal compatible and there is an active developer that is a portal expert on that team. <BR/><BR/>As for LGPL vs Apache2, there are some conflicts. You cannot release an Apache2 product with an LGPL dependency to my knowledge.<BR/><BR/>Best thing is to ask around on the MyFaces mailing listAnonymoushttps://www.blogger.com/profile/12230997086550680222noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-74928381912440904982008-07-16T01:17:00.000-06:002008-07-16T01:17:00.000-06:00Hi Andrew,The 2nd example from myface's wiki for l...Hi Andrew,<BR/><BR/>The 2nd example from myface's wiki for lazy loading doesn't work too well for me. The root node already has a list of folder nodes from its own getChildren(); however, when I click + to expand the root node, tree2 actually calls getChildren() of each of the folder nodes and jump one level ahead. It results in dozens of expensive web service calls to get the children of each node.<BR/><BR/>By looking your implementation, I couldn't tell if it has solved this look-one-level-ahead problem. The war seems to be loading nodes very quickly, but then again, it was only adding dummy nodes. Also, my project will be using tree2 in a portal, and am not sure if ajaxAnywhere would introduce incompatibilities? And finally, is the LGPL compatible with Apache-style license which my project is under? <BR/><BR/>I look forward to any comments/suggestions/advice. Thanks.<BR/><BR/>-- JimJimhttps://www.blogger.com/profile/18181399816492585880noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-72927868484390342502008-06-17T02:35:00.000-06:002008-06-17T02:35:00.000-06:00Agree, good post.Please keep them coming.Agree, good post.<BR/>Please keep them coming.Unknownhttps://www.blogger.com/profile/01570516284530050247noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-81984499543153730812008-06-07T15:38:00.000-06:002008-06-07T15:38:00.000-06:00Very good post, Andrew!Very good post, Andrew!Hazem Salehhttps://www.blogger.com/profile/11862807848530824735noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-64965015248935827972008-04-09T06:44:00.000-06:002008-04-09T06:44:00.000-06:00Thank You. Helped Loads.Thank You. Helped Loads.jaychttps://www.blogger.com/profile/13877592677475973611noreply@blogger.comtag:blogger.com,1999:blog-29717104.post-46036940633134940502008-03-21T08:27:00.000-06:002008-03-21T08:27:00.000-06:00Hey Andrew. Nice summary :)[quote]Components do no...Hey Andrew. Nice summary :)<BR/><BR/>[quote]Components do not have to use renderers to produce their content, but it is considered bad design to use the encode methods in a component to render a response.[/quote]<BR/><BR/>/me just went momentarily deafAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-29717104.post-79042928810089590402008-03-19T02:12:00.000-06:002008-03-19T02:12:00.000-06:00Great post! thank youGreat post! thank youPatmanhttps://www.blogger.com/profile/03752201336327847422noreply@blogger.com