myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Top 10 Questions" by Dennis Byrne
Date Sun, 19 Mar 2006 05:56:20 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by Dennis Byrne:
http://wiki.apache.org/myfaces/Top_10_Questions

The comment on the change is:
duplication of effort

------------------------------------------------------------------------------
+ deleted
- {{{
- Please keep in mind this page is intended to be the top ten questions of the "community"
rather than one or two people.
- }}}
  
- == 1.) "My PhaseListener is called twice" ==
- 
- The JSF specification requires any JSF implementation to automatically load /WEB-INF/faces-config.xml
at startup.  There is consequently no need for the following context parameter:
- 
- {{{
- <context-param>
-    <param-name>javax.faces.CONFIG_FILES</param-name>
-    <param-value>/WEB-INF/faces-config.xml</param-value>
- </context-param>
- }}}
- 
- Putting this context parameter in your deployment descriptor will force any JSF implementation
to load the configuration twice, therefore registering each phase listener twice.
- 
- == 2.) "Action listeners and actions for my commands on dataTables do not fire" ==
- 
- Action listeners and actions are not invoked when the action source ( h:commandLink, h:commandButton
) is not rendered.  When our action sources are on a dataTable, and  the value attribute of
the dataTable points to a request scoped data source, the action source just isn't rendered
on a subsequent request.
- 
- {{{
- <h:dataTable value="#{requestScopedBean.dataModel.wrappedData}" />
- 	<h:column>
- 		<h:commandLink value="click here" action="#{backingBean.willNotFire}" />
- 	</h:column>
- </h:dataTable>
- }}}
- 
- The action source ( h:commandLink, h:commandButton ), is not rendered because the data source
does not exist during a subsequent request ( it was garbage collected after the first response
was completed).
- 
- To solve this problem, use t:saveState or put the request scoped backing bean in session
scope.
- 
- {{{
- <t:saveState value="#{myRequestScopedBean.dataModel.wrappedData}" />
- }}}
- 
- t:saveState is preffered over a session scoped solution.
- 

Mime
View raw message