Simplify external view loading requirements #809
Comments
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
1 similar comment
|
@glassfishrobot Commented |
|
@glassfishrobot Commented (1) Provide the ability to load Facelet views from a JAR without writing a custom class. Basically, all we'd need is to define a mapping between a URL and a view within a resource library. A sensible default with the ability to override it in faces-config.xml would suffice. |
|
@glassfishrobot Commented Make flows reusable http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-730 |
|
@glassfishrobot Commented 3. It makes it difficult to distinguish between requests for view ids vs. other types of resources. Consider this ad hoc log output from getResource(): INFO: getResource: /index.xhtml Add to the above the use of ExternalContext.getResource() to determine the existence of a view for conditional navigation, and you have a good idea of all the places that need to be touched to accommodate this new API. |
|
@glassfishrobot Commented Usage1: During RestoreViewPhase when trying to load a page to get its csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527) Usage2: When trying to render a button whose action uses conditional csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527) Usage3: When trying to get the viewId on an initial page request. csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:528) Usage4: When trying to serve up a resource request from the filesystem. csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:528) Usage5: When trying to find a ScriptComponent Resource for a Composite csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527) Usage6: When trying to render out the markup for a stylesheet reference csf.context.ExternalContextImpl.getResource(ExternalContextImpl.java:527) |
|
@glassfishrobot Commented This might make it possible to deprecated the Facelets ResourceResolver. |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented
I know the issue is resolved and closed, but I'm just wondering about the original intend. The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource(). But, this is not what happens at all in JSF 2.1. Implicit navigation and all other cases that need to interact with the physical location of the view already go through the ResourceResolver. This is clear from the stacktraces Ed posted on 24/Feb/12 09:13 PM So, in order to satisfy "we only want to search our external repositories when a view id is requested", the existing ResourceResolver already fully did the job and "2. It requires hooking into multiple locations." doesn't apply. Maybe I'm completely missing something though. The new mechanism does seem inline with the comment made by kito on 19/Apr/11 |
|
@glassfishrobot Commented
Right. The issue was originally filed back in 2010, before 2.1 existed. In 2.0.x, Mojarra's MultiViewHandler.convertViewId() contains the following logic:
This code is checking for the presence of a view corresponding to a viewId by calling ExternalContext.getResource(). This of course fails for views that are known to the ResourceResolver, but are not accessible via ExternalContext.getResource(). As such, frameworks that plug into the ResourceResolver to enhance the set of views that are available must also plug into ExternalContext.getResource(). We addressed this in 2.1.x with the addition of ViewDeclarationLanguage.viewExists(). As of 2.1.x, the above MultiViewHandler code has been replaced with:
And FaceletViewHandlingStrategy implements this as:
This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource(). |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented
Okay, it's clear now
You're welcome! Incidentally, it's for that page mostly that I was wondering about the intent of this issue Thanks again for explaining. |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
@glassfishrobot Commented |
|
In Facelets 1.x, it was possible to implement load views from external locations (such as the class path,
or a repository) by providing a ResourceResolver implementation.
The ResourceResolver is also present in JSF 2, so this is still possible. However, there is a new
requirement. Implicit navigation calls ExternalContext.getResource() to determine whether a view id
corresponds to a physical resource. If ExternalContext.getResource() returns a non-null URL, implicit
navigation to the view id is allowed.
This contract is not ideal, as:
1. It is non-obvious.
2. It requires hooking into multiple locations.
3. It makes it difficult to distinguish between requests for view ids vs. other types of resources.
Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we
only want to search our external repositories when a view id is requested, but not, say, when someone
calls getResource() to load some other type of file (eg. a style sheet).
We need to introduce a cleaner contract that simplifies the responsibilities for custom view loading
implementations.
Environment
Operating System: All
Platform: Macintosh
Affected Versions
[2.0]
The text was updated successfully, but these errors were encountered: