Hi Leonardo,
If the <request-path> element could have EL then that might be a convenient way to dynamically determine the CDN from a Java class at runtime.
Regarding portlets, I would rather not override jsf.js — Instead I would prefer JavaScript extension points.
Thanks,
Neil
> On Oct 23, 2014, at 5:09 PM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
>
> 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
>>>
>>>
>>>
>>
>>