Richfaces 重点技术精讲

转载 richfaces 精讲

http://hintcnuie.iteye.com/blog/127309

 

关键字: ajax4jsf richfaces 总结

Ajax components attributes help RichFaces to expose its features. Most of the attributes have default values. Thus, you can start working with RichFaces without knowing the usage of these attribute. However, their usage allows to tune the required Ajax behavior very smoothly.

Re-Rendering

reRender is a key attribute. It allows to point to the area(s) on a page that should be updated as a response on Ajax interaction. The value of the reRender attribute is an id of the JSF component or an id list. This is a simple example:

...
<a4j:commandButton value="update" reRender="infoBlock"/>
    ....
<h:panelGrid id="infoBlock">
    .....
</h:panelGrid>
.....

reRender uses UIComponent.findComponent() algorithm (with some additional exceptions) to find the component in the component tree. As you see, the algorithm presumes several steps. Each other step is used if the previous step is not successful. Therefore, you can define how fast the component is found mentioning it more precisely. The following example shows the difference in approaches (both buttons will work successfully):

.....
<h:form id="form1">
    ....
    <a4j:commandButton value="Usual Way" reRender="infoBlock, infoBlock2" />
    <a4j:commandButton value="Shortcut" reRender=":infoBlockl,:sv:infoBlock2" />
    .....
</h:form>
<h:panelGrid id="infoBlock">
    .....
</h:panelGrid>
.....
<f:subview id="sv">
    <h:panelGrid id="infoBlock2">
    .....
    </h:panelGrid>
    .....
</f:subview>

You can use JSF EL expression as a value of the reRender attribute. It might be a property of types Set, Collection, Array or simple String. The EL for reRender is resolved right before the Render Response phase. Hence, you can calculate what should be re-rendered on any previous phase during the Ajax request processing.

Most common problem with using reRender is pointing it to the component that has a 'rendered' attribute. Note, that JSF does not mark the place in the browser DOM where the outcome of the component should be placed in case the 'rendered' condition returns false. Therefore, after the component becomes rendered during the Ajax request, RichFaces delivers the rendered code to the client, but does not update a page, because the place for update is unknown. You need to point to one of the parent components that has no 'rendered' attribute. As an alternative, you can wrap the component with a4j:outputPanel layout="none".

ajaxRendered attribute of the a4j:outputPanel set to true allows to define the area of the page that will be re-rendered even if it is not pointed in the reRender attribute explicitly. It might be useful if you have an area on a page that should be updated as a response on any Ajax request. For example, the following code allows to output error messages regardless of what Ajax request causes the Validation phase failed.

<a4j:outputPanel ajaxRendered="true">
    <h:messages />
</a4j:outputPanel>

limitToList attribute allows to dismiss the behavior of the a4j:outputPanel ajaxRendered attribute. limitToList = "false" means to update only the area(s) that mentioned in the reRender attribute explicitly. All output panels with ajaxRendered="true" will be ignored.

Queue and Traffic Flood Protection

eventsQueue attribute defines the name of the queue that will be used to order upcoming Ajax requests. By default, RichFaces does not queue Ajax requests. If events are produced simultaneously, they will come to the server simultaneously. JSF implementations (especially, the very first ones) does not guaranty that the request that comes first will be served or passed into the JSF lifecycle first. The order how the server side data will be modified in case of simultaneous request might be unpredictable. Usage of eventsQueue attribute allows to avoid possible mess. Define the queue name explicitly, if you expect intensive Ajax traffic in your application.

The next request posted in the same queue will wait until the previos one is not processed and Ajax Response is returned back if the eventsQueue attribute is defined. In addition, Richfaces starts to remove from the queue 'similar' requests. 'Similar' requests are the requests produced by the same event. For example, according to the following code, only the newest request will be sent to the server if a user types very fast and has typed the several characters already before the previous Ajax Response is back. 

<h:inputText value="#{userBean.name}">
    <a4j:support event="onkeyup" eventsQueue="foo" reRender="bar" />
</h:inputText>
RichFaces allows to organize a page flow inside the a4j:include component. This is a typical scenario for Wizard like behavior. The new content is rendered inside the a4j:include area. The content is taken from the navigation rule of the faces configuration file (usually, the faces-config.xml). Note, that the content of the "wizard" is not isolated from the rest of the page. The included page should not have own f:view (it does not matter if you use facelets). You need to have an Ajax component inside the a4j:include to navigate between the wizard pages. Otherwize, the whole page update will be performed.
If you want to involve the server side validators and navigate to the next page only if the Validation phase is passed successfully, you can replace h:commandButton with a4j:commandButton and point to the action method that navigates to the next page. If Validation process fails, the partial page update will occur and a user will see an error message. Otherwize, the application proceeds to the next page. Make sure, you define <redirect /> option for the navigation rule to avoid memory leaks.