As you already should know, a PhaseListener object can intercept requests in the Restore View Phase phase of the JSF lifecycle. You can take advantage of this and access static resources. You may use a custom flag in the request URL and call the getFacesContext().getViewRoot().getViewId() method or you can take a value from the parameters of HttpServletRequest by calling the getFacesContext().getExternalContext().getRequestParameterMap() method. We have two problems here, a small problem and a big problem. The small one consists in writing a PhaseListener object for each component, and the big one consists in the fact that PhaseListener objects, configured in different faces-config.xml descriptors, are provided sequentially, with no established order.

This in not a very common task for a renderer class, but it can be plausible if we keep in mind that process events are fired up after every phase of the JSF lifecycle, except Restore View Phase and Renderer Response Phase. Especially, we are interested in phase 2, or Apply Request Values Phase, when the renderer class can provide the required static resources or make a dynamic call possible (at the end, don't forget to call the FacesContext.responseComplete—this will skip the rendering phase, Render Response Phase). The main problem of this approach is reflected in the performance, since we are dealing with tasks that consume important time to be accomplished.

This is the most common approach and, at first look, the best one. Direct access is based on a simple concept: resources are packaged under the web module and are accessible through URLs or servlets (rarely, since this is time consuming and requires more configurations in the application's descriptors). At second look, this approach requires additional configurations and it must avoid repeating resource's names across components—especially when the components may appear on the same page.

We kept the best for the end! If we take a look at the Java BluePrints Solution Catalog and Java BluePrints Pet Store Demo 2.0 (developed by the Java BluePrints team), we notice that they used Shale Remoting libraries (see http://shale.apache.org/index.html) to accomplish static/dynamic tasks. Actually, Shale Remoting is just one feature of the Apache Shale project, which is a web application framework, fundamentally based on JavaServer Faces. As the Shale Remoting definition states: