Gang -
More feedback...
Index: javax/faces/application/ResourceHandler.java
===================================================================
--- javax/faces/application/ResourceHandler.java (revision 8845)
+++ javax/faces/application/ResourceHandler.java (revision 11719)
+ * <p>PENDING(edburns): I think we need to put an additional check
+ * in to avoid returning false hits from this method when a
+ * viewResource happens to be named the same as one of the templates
+ * in a resource library contract. Perhaps we could set some kind
+ * of flag in the tag handler of all facelet tags that are valid for
+ * using resource library contracts (maybe just ui:composition and
+ * ui:decorate) and make it so the getResourceLibraryContracts part
+ * of this method only takes effect if that flag is set?</p>
I am not yet up to speed on resource library contracts, but wanted to
point out this PENDING comment in case it needs to be addressed before
we go final.
+ * @param context the {_at_link FacesContext} for this request.
+
+ * @param resourceName the name of the resource to be interpreted
as a view
+ * by the {_at_link javax.faces.view.ViewDeclarationLanguage}.
+
+ * @throws NullPointerException if <code>resourceName</code> is
+ * {_at_code null}.
+
+ * @return a newly created <code>Resource</code> instance, suitable
+ * for use by the {_at_link javax.faces.view.ViewDeclarationLanguage}.
+ *
+ * @since 2.2
+
+ */
+
+ public Resource createViewResource(FacesContext context, String
resourceName) {
Is resourceName just a viewId? If yes, perhaps we should call it that
for clarify. Or, alternatively, doc that resourceName == view id.
It sounds like this method replaces ResourceResolver.resolveUrl(),
though one difference is that resolveUrl() simply returns an URL,
whereas implementations of createViewResource() are responsible for
providing a (signifcantly more complex) Resource instance.
What bits of the Resource returned from createViewResource() are
actually used? Just the URL? The content type? Library name?
Response headers? Request path?
Looking at Mojarra source code, it seems that only the URL is used.
Perhaps the doc should be clearer about which of the Resource properties
are honored in the view creation case. Otherwise, folks may implement a
custom ResourceHandler and be surprised that, for example, the response
headers returned via createViewResource() are not honored.
It is awkward that code that previously coughed up an URL is now
required to cough up a Resource, even though everything on the Resource
other than the URL will be ignored.
Is the now deprecated ResourceResolver API still functional - ie. are
existing ResourceResolver implementations still guaranteed to work?
Okay, venturing into the realm of completely pointless observations, but
since I am now going to be forced to port my ResourceResolver over to a
ResourceHandler... Resource should not have exposed separate abstract
methods for getInputStream() and getURL(), since it should be possible
to implement getInputStream() in terms of getURL(). Yep. There's some
JSF 2.0 feedback that is 4 years too late! :-/
Andy