Need method to map viewId to resource path #719
Comments
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented Here are the usages that I have discovered thus far: Usage1: During RestoreViewPhase when trying to load a page to get its Usage2: When trying to render a button whose action uses conditional Usage3: When trying to get the viewId on an initial page request. Usage4: When trying to serve up a resource request from the filesystem. Usage5: When trying to find a ScriptComponent Resource for a Composite Usage6: When trying to render out the markup for a stylesheet reference There may be others, possibly from the application space as well. Both 719 and 809 want some kind of API to allow loading resources. |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented The code that appears to be causing the failures is below. What it looks like to me is that if toStream is not an instanceof ClientResourceInfo we just end up going off into the weeds. public InputStream getInputStream(ResourceInfo toStream, FacesContext ctx) // PENDING(edburns): this is a sub-optimal implementation choice InputStream in = null; if (toStream instanceof ClientResourceInfo) { in = getInputStreamFromClientInfo(resource, ctx); { resource.copy(resourceWithoutLocalePrefix); } } } else { // PENDING(edburns): get the input stream from the facelet ResourceInfo. <------- "Offending Code" } return in; } |
|
@glassfishrobot Commented SECTION: 1085 changesM jsf-api/src/main/java/javax/faces/context/ExternalContext.java
M jsf-ri/src/main/java/com/sun/faces/context/ExternalContextImpl.java
A test/agnostic/externalContext
SECTION: 719 changesM jsf-ri/src/main/java/com/sun/faces/application/resource/ClasspathResourceHelper.java
SECTION: Build changesM jsf-ri/systest/build-tests.xml
This reduces the test count by two on the old side, but increases it M test/agnostic/pom.xml
M test/pom.xml
SECTION: 730 changes M jsf-api/src/main/java/javax/faces/flow/Flow.java
Sending jsf-api/src/main/java/javax/faces/context/ExternalContext.java |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
The current JSF specification does not provide a standard plugable mechanism for
mapping a viewId to the resource path for the resource that will render the
view. Although the specification doesn't state that the requested viewId be
literally the resource path of the VDL document some parts of the RI assume this
with code similar to:
String viewId = FacesContext.getViewRoot().getViewId();
Object resource = externalContext.getResource(viewId);
This breaks applications that want to have some type of indirection or mapping
between viewIds and physical resources (e.g. viewId "/x/y/z" is rendered using
document "/a/b/foo.jspx").
Apache Trinidad solves this problem with a plugable interface called a
PageResolver (see
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/index.html). This may
server as an model for how to provide this capability in the standard.
Environment
Operating System: All
Platform: All
Affected Versions
[2.0]
The text was updated successfully, but these errors were encountered: