This is actually a problem that we are going to have to solve when we develop the alloy:dataExporter component (see
FACES-1910).
There is a limitation to the design of the JSF2 ResourceHandler that is something that we will probably need to consider.
Specifically, the ResourceHandler.handleResourceRequest(FacesContext) method is only able to figure out what data to return in the response by examining request parameters specified on the URL.
So when we consider the following (potential/future) usage of alloy:dataExporter:
<alloy:datatable id="tbl" value="#{myModelBean.cars}" var="car">
...
</alloy:datatable>
<alloy:dataexporter type="xls" for="tbl" fileName="cars" />
One big problem that is a consequence of this limitation is that the ResourceHandler delegation chain is invoked by the portlet bridge (or FacesServlet) without first running the JSF lifecycle. So the ExportResourceHandler will probably have to execute the RESTORE_VIEW phase in order to get access the component tree. This can probably be done by developing a PhaseListener that short-circuits the JSF lifecycle by calling facesContext.responseComplete() at the end of RESTORE_VIEW.
public class ResourcePhaseListener implements PhaseListener {
public void afterPhase(javax.faces.event.PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
String libraryName = facesContext.getExternalContext().getRequestParameterMap("ln");
if ("export".equals(libraryName)) {
facesContext.responseComplete();
}
}
public void beforePhase(javax.faces.event.PhaseEvent event) {
}
public javax.faces.event.PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
}
Here is how we could execute the JSF lifecycle from the ExportResourceHandler:
// Get the lifecycle
Lifecycle lifecycle = lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
// Execute only the RESTORE_VIEW phase by relying on the ResourcePhaseListener
lifecycle.execute(facesContext);
But in order for the RESTORE_VIEW phase to work, the viewId and the viewState would need to be present in the URL:
public class ExportResourceHandler {
...
public String getRequestPath() {
// Need to add javax.portlet.faces.Bridge.FACES_VIEW_ID_PARAMETER "_jsfBridgeViewId" with the target viewId
// Need to add javax.faces.render.ResponseStateManager.VIEW_STATE_PARAM "javax.faces.ViewState" with the viewState
}
...
}
Getting the value of "javax.faces.ViewState" might prove to be
very very difficult. The way we currently do it in the bridge is that we have
ResponseWriterBridgeImpl.java intercept it. The problem is that Mojarra/MyFaces doesn't write it out until just before the closing </form> element rendered by the h:form tag. That means it happens too late -- after the Resouce.getRequestPath() method has been called. Again, a very very difficult problem.
But we might also need to provide a way for the JSF Lifecycle to determine the target viewId. In order to do this, we could provide an ExternalContextFactory implementation [4] that "wraps" the others in the ExternalContext delegation chain. Something like this:
public class ExternalContextResourceImpl extends ExternalContextWrapper {
public String getRequestPathInfo() {
// return the viewId from the URL request parameter
// BUT MAKE SURE THAT THE viewId HAS VALID CHARACTERS
// (meaning, it does not contain a colon (:) character)
// See: https://issues.liferay.com/browse/FACES-1917
}
}
Anyway, all of this code is just an example of some ideas that I have. Not sure it will work, since we haven't developed alloy:dataExporter yet.
