>>>>> On Mon, 11 Mar 2013 21:31:47 -0400, Andy Schwartz <andy.schwartz_at_oracle.com> said:
AS> I am not yet up to speed on resource library contracts, but wanted to
AS> point out this PENDING comment in case it needs to be addressed before
AS> we go final.
Thanks, yes I saw that from Leonardo's comments also. I've addressed it.
AS> + * @param context the {_at_link FacesContext} for this request.
AS> +
AS> + * @param resourceName the name of the resource to be interpreted
AS> as a view
AS> + * by the {_at_link javax.faces.view.ViewDeclarationLanguage}.
AS> +
AS> + * @throws NullPointerException if <code>resourceName</code> is
AS> + * {_at_code null}.
AS> +
AS> + * @return a newly created <code>Resource</code> instance, suitable
AS> + * for use by the {_at_link javax.faces.view.ViewDeclarationLanguage}.
AS> + *
AS> + * @since 2.2
AS> +
AS> + */
AS> +
AS> + public Resource createViewResource(FacesContext context, String
AS> resourceName) {
AS> Is resourceName just a viewId? If yes, perhaps we should call it that
AS> for clarify. Or, alternatively, doc that resourceName == view id.
I don't know if that is always true. For example, this method is used
to load templates. Now, while a template client is usually a viewId,
the template is certainly not a viewId. Also, every other create*
method on ResourceHandler has resourceName. I'd like to stick with
resourceName.
AS> It sounds like this method replaces ResourceResolver.resolveUrl(),
AS> though one difference is that resolveUrl() simply returns an URL,
AS> whereas implementations of createViewResource() are responsible for
AS> providing a (signifcantly more complex) Resource instance.
AS> What bits of the Resource returned from createViewResource() are
AS> actually used? Just the URL? The content type? Library name?
AS> Response headers? Request path?
AS> Looking at Mojarra source code, it seems that only the URL is used.
AS> Perhaps the doc should be clearer about which of the Resource properties
AS> are honored in the view creation case. Otherwise, folks may implement a
AS> custom ResourceHandler and be surprised that, for example, the response
AS> headers returned via createViewResource() are not honored.
AS> It is awkward that code that previously coughed up an URL is now
AS> required to cough up a Resource, even though everything on the Resource
AS> other than the URL will be ignored.
I have created a new abstract class, ViewResource, with one method,
getURL(), and made it be the superclass of Resource. I made
createViewResource() return ViewResource instead of Resource.
AS> Is the now deprecated ResourceResolver API still functional - ie. are
AS> existing ResourceResolver implementations still guaranteed to work?
Yes, it must still work.
Ed
--