Hi Ed,
changing the topic...
Am 12.07.2012 um 00:12 schrieb Edward Burns:
>>>>>> On Sun, 8 Jul 2012 17:14:18 +0200, Frank Caputo <frank_at_frankcaputo.de> said:
>
> FC> since there are no followups on this, I propose the following change
> FC> to javax.faces.application.Resource:
>
> Thank you so much for putting this in terms that can readily be dropped
> into the spec.
>
> FC> ------------- SPEC CHANGE 1 -----------------------------
>
> FC> Add a method getResourceId():
>
> FC> /**
> FC> * Return the resource identifier according to the specification
> FC> * in JSF.2.6.1.3 of the spec prose document <a
> FC> * href="../../../overview-summary.html#prose_document">linked in
> FC> * the overview summary</a>.
> FC> *
> FC> * @return the resource identifier
> FC> *
> FC> * @since 2.2
> FC> */
> FC> public abstract String getResourceId();
>
> What do you intend for those parts of the id that are optional and not
> present in the actual persistent representation of the Resource?
Currently all optional parts except for the version are specified to be rendered in the query string. And Mojarra renders also the version in the query string.
Seems like we need a resource identifier without versions for relative resources to work.
> FC> ------------- SPEC CHANGE 2 -----------------------------
>
> FC> Change the javadoc of getRequestPath():
>
> FC> * <ul><p><code>result = <em>contextRoot</em> + '/' +
> FC> * <em>facesServletMapping</em> + {_at_link
> FC> * ResourceHandler#RESOURCE_IDENTIFIER} + '/' + {_at_link
> FC> * #getResourceId()}</code></p></ul>
>
> FC> * <ul><p><code>result = <em>contextRoot</em> + {_at_link
> FC> * ResourceHandler#RESOURCE_IDENTIFIER} + {_at_link #getResourceId()} +
> FC> * <em>facesServletMapping</em></code></p></ul>
>
> FC> public abstract String getRequestPath();
>
> The reason we had resourceName there before, which you've changed to
> getResourceId(), is that you don't need to encode all those optional
> parts, and in-fact, you don't want to because you want to let the server
> decide how best to serve up a resource based on just the required parts.
>
> I expect this is related to 947-RelativeResourceHandler. If so, how
> does this proposal address that?
The benefit is that there are no more query strings, which is (together with prefix mapping) necessary to make relative resources possible as I stated here:
http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-05/message/35
About versions in the URL: If a version is supposed to be fixed, rendering it out, would help the client caching it. This way you can simply set the Expires HTTP header to next year and the client never asks the server again (it even doesn't ask for 304), because the URL changes, when the resource changes. This is an enormous performance boost for high traffic websites with many resources. It even makes integrating a CDN a 5 minute task.
Ciao Frank