Hi
I have created this issue, since I couldn't found any similar issue in the spec:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1330 Allow
flexible resource mapping for .js or .css or other files served by
ResourceHandler
There are other issues that are related somehow, but are not exactly the same:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-706
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-598
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-947
The idea to solve this could be add some extra xml config on
faces-config.xml file.
I know it doesn't sound too appealing to create more config in faces-config.xml,
but please note this is done for tuning purposes, specially for
production stage.
In the past I tried some xml like this:
<!-- Indicate this library has another name, so if libraryC is used,
resources should be redirected to libraryC1 -->
<library>
<library-name>libraryC</library-name>
<redirect-name>libraryC1</redirect-name>
</library>
<!-- Allow to customize the request path generated, to do things like
take library resources from a Content Delivery Network (CDN) or just
take it directly from an specified location. Note it is responsibility
of the developer to configure it properly, and the resources should
exists locally under the library name selected. -->
<library>
<library-name>libraryB</library-name>
<request-path>
http://someaddress.com/alternatePath/#{resourceName}</request-path>
</library>
For the problem we have (portlets needs to override jsf.js), it would be only
necessary to provide an entry on faces-config.xml and that's it.
Maybe we can imagine something to simplify this part.
regards,
Leonardo Uribe
2014-10-23 15:35 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
> Hi Kito,
>
> JSF Portlet Bridges that target JSF 2.2 + Portlet 3.0 will definitely have
> to jump through some hoops. Is there a particular JavaScript trick you would
> recommend?
>
> Best Regards,
>
> Neil
>
> On Oct 23, 2014, at 4:13 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
>
> Neil,
>
> I agree that some sort of pluggability would be useful. It might allow
> libraries such as PrimeFaces to use the standard APIs but still use their
> own implementations (right now, PrimeFaces' JS side is completely
> proprietary and uses jQuery internally).
>
> Out of curiosity, though, couldn't you override the JSF JS functions using
> some of the standard JavaScript tricks?
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com | @jsfcentral
> +1 203-998-0403
>
> * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
> * JSFCentral Interviews Podcast:
> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
> On Wed, Oct 22, 2014 at 5:13 PM, Neil Griffin
> <neil.griffin_at_portletfaces.org> wrote:
>>
>> On Oct 22, 2014, at 4:27 PM, Edward Burns <edward.burns_at_oracle.com> wrote:
>>
>>
>> On Tue, 14 Oct 2014 19:30:03 +0200, Frank Caputo <frank_at_frankcaputo.de>
>> said:
>>
>>
>> FC> I'd like to see a complete rework of JSF's JavaScript library, which
>> FC> will make it work well together with all those modern JS frameworks.
>>
>> EB> I can't countenance a complete rework but I can entertain incremental
>> EB> changes, such as what Neil mentions here:
>>
>> On Tue, 14 Oct 2014 14:35:15 -0400, Neil Griffin
>> <neil.griffin_at_portletfaces.org> said:
>>
>>
>> NG> One of the things that the 362 (Portlet 3.0) EG has discussed
>> NG> verbally with Ed Burns is the need for the JSF Portlet Bridge to
>> NG> somehow decorate the jsf.ajax.request() and jsf.ajax.response()
>> NG> JavaScript functions. Perhaps this requirement could be included in
>> NG> a rework of the jsf.js library.
>>
>> EB> Neil, can you summarize the current thinking on how this will be done
>> in
>> EB> JSR-362 Portlet 3.0?
>>
>>
>> Not the prettiest solution... but we discussed the possibility of having
>> the JSF Portlet Bridge’s ResourceHandler deliver a transformed jsf.js
>> resource such that the jsf.ajax.request and jsf.ajax.response functions
>> would be renamed to something like jsf_impl.ajax.request and
>> jsf_impl.ajax.response respectively. The JSF Portlet Bridge would need to
>> provide its own implementations of jsf.ajax.request and jsf.ajax.response in
>> order to handle the Portlet 3.0 requirements and then call-through to the
>> jsf_impl.ajax.request and jsf_impl.ajax.response functions.
>>
>> Another possibility would be for the JSF Portlet Bridge to provide its own
>> JSF 2.3 implementation of jsf.js, but this has not been necessary for JSF
>> 2.0/2.1/2.2 and I would prefer to avoid it.
>>
>> My preference would be some type of extension mechanism at the level of
>> the JSF JavaScript API.
>>
>> Thanks,
>>
>> Neil
>>
>>
>>
>
>