Hi,
since there are no followups on this, I propose the following change to javax.faces.application.Resource:
------------- SPEC CHANGE 1 -----------------------------
Add a method getResourceId():
/**
* Return the resource identifier according to the specification
* in JSF.2.6.1.3 of the spec prose document <a
* href="../../../overview-summary.html#prose_document">linked in
* the overview summary</a>.
*
* @return the resource identifier
*
* @since 2.2
*/
public abstract String getResourceId();
------------- SPEC CHANGE 2 -----------------------------
Change the javadoc of getRequestPath():
/**
* <p class="changed_added_2_0"><span
* class="changed_modified_2_2">Return</span> a path to this
* resource such that, when the browser resolves it against the base
* URI for the view that includes the resource, and issues a GET
* request to the resultant fully qualified URL, the bytes of the
* resource are returned in response.</p>
*
* <div class="changed_added_2_0">
*
* <p>The default implementation must
* implement the following algorithm. For discussion, the return
* result from this method will be called <em>result</em>.</p>
*
* <ul>
*
* <li><p>Get the context-root for this web application, not ending
* in slash. For discussion this will be called
* <em>contextRoot</em>.</p></li>
*
* <li><p>Discover if the <code>FacesServlet</code> is prefix or
* extension mapped, and the value of the mapping (including the
* leading '.' in the case of extension mapping). For discussion,
* this will be <em>facesServletMapping</em>.</p>
*
* <p>If prefix mapped, <em>result</em> must be</p>
*
* <ul><p><code>result = <em>contextRoot</em> + '/' +
* <em>facesServletMapping</em> + {_at_link
* ResourceHandler#RESOURCE_IDENTIFIER} + '/' + {_at_link
* #getResourceId()}</code></p></ul>
*
* <p>If extension mapped, <em>result</em> must be</p>
*
* <ul><p><code>result = <em>contextRoot</em> + {_at_link
* ResourceHandler#RESOURCE_IDENTIFIER} + {_at_link #getResourceId()} +
* <em>facesServletMapping</em></code></p></ul>
*
* </li>
*
* <li><p>Make it portlet safe by passing the result through {_at_link
* ViewHandler#getResourceURL}.</p></li>
*
* </ul>
* </div>
*
* @return the path to this resource, intended to be included in the
* encoded view that is sent to the browser when sending a faces
* response.
*/
public abstract String getRequestPath();
------------- IMPORTANT NOTE -----------------------------
This will change the behavior, how resource urls are generated. Is this considered an incompatible API change? Some client code (e.g. JavaScript) might require the old behavior.
Ciao Frank
Am 22.05.2012 um 22:33 schrieb Frank Caputo:
> Hi EG,
>
> I think we nearly have it, with a little limitation to prefix-mapped resources and non versioned resources.
>
> If the ResourceHandler would always generate urls without the question mark, one could use the usual references with ../
>
> I don't understand, why the javadoc for Resource#getRequestPath() doesn't simply reference section 2.6.1.3 of the spec and require a valid resource identifier instead of #getResourceName() for the result.
>
> Let's simply change the javadoc here, if there is no good reason to leave it as is.
>
> Loading the stylesheet from http://localhost:8080/faces/javax.faces.resource/css/style.css would make it possible to reference the image with ../images/expert-draft-bg.png
>
> Having this, you can simply use css files from the designer as you get them.
>
> If all this comes to skinning, we could simply prefix the path with the skin as supposed by Hanspeters comment.
>
> About all those minifying and combining comments. I think, this should not be part of the spec because it is a special case for css and js and no generic resource problem.
>
> To address it a project similar to DeltaSpikr for CDI might also be useful for JSF.
>
>
> Frank
>
> Am 21.05.2012 um 16:12 schrieb Edward Burns <edward.burns_at_oracle.com>:
>
>> EB-> There's basically three issues I want to get done before the Public
>> EB-> Review Draft
>>
>> EB-> - 730 Flows
>>
>> EB-> - 971 MultiTemplating
>>
>> Frank, as soon as one starts thinking about 971-Multitemplating, one
>> runs quickly into Jakob Korherr's 947-RelativeResourceHandler. We made
>> some progress on this but I had to put it aside for other work deemed
>> more important.
>>
>> Frank, can you please take a look at 947-RelativeResourceHandler and
>> send me a private mail with a proposal for discussion, which I will
>> refine and quickly, AND TRANSPARENTLY, turn around and send to the EG?
>> In the name of transparency, you may CC, the EG if you must on this
>> initial mail, but I feel doing so would unnecessarily muddy the
>> discussion, considering my promise to have the "real" discussion on the
>> EG. If you do Cc the EG on this private mail to me, please make it
>> clear that the EG should not reply to the mail and instead wait for the
>> one that actually calls for discussion.
>>
>> Basically, the latest on the issue is that we need to craft the feature
>> in light of a simplifying assumption that only prefix-mapped resources
>> are supported.
>>
>> Thanks,
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | homepage: | http://ridingthecrest.com/
>