Hi Sven, Thanks for the great feedback.
The reason it is done that way is because section 11.1 of the JSF spec suggests that this is how JSF portlets should work. It may be inefficient, but as I understand the spec it is definitely not wrong. If we did a Restore View on render requests then I'm not sure what the consequences would be. Even if it made things faster now I'm afraid of going against the intentions of the spec. Something the spec does give us lots of flexibility on is the implementation of Render Response. Maybe we could come up with some optimizations there. Granted, I'm taking a 10,000 foot view here and you have obviously given this more thought than I. Would you be willing to do some more research in this area? We might be able to get a spec change or clarification into JSF 1.3. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert > -----Original Message----- > From: Sven Schulz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 18, 2005 11:09 AM > To: [email protected] > Subject: MyFacesGenericPortlet behaviour > > I'm using MyFaces within JBoss Portal 2.0 RC1. I wonder if the portlet > bridge (i.e. MyFacesGenericPortlet) is handling render requests (doView, > doHelp, doEdit) correctly. > > Assume that we have a portal with two portlets on the same page. When a > action request comes in for one of them the whole JSF lifecycle is > executed > for this portlet. The other is activated by a render request (doView). The > current implementation of the bridge skips all lifecycle stages up to the > render response phase. This means that the component tree is not restored. > As a consequence all components are recreated from scratch. This is > inefficient and in my opinion wrong. I think at least the Restore View > phase > should be executed for every incoming request. Why not executing all > phases? > > -- > 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail > +++ GMX - die erste Adresse f�r Mail, Message, More +++
