Hi
Yes, something like that. In MyFaces for example, there is a code
that according to the project stage (dev or prod) it uses the
uncompressed or the compressed version of the file.
In MyFaces we have two paths:
/META-INF/internal-resources (for uncompressed versions of the js files)
/META-INF/resources (for compressed and production-ready versions of
the js files)
and a custom resource handler that uses internal-resources if project
stage is development.
The central point is sometimes you need to override the resources, and to
do that you need to create custom implementations of ResourceHandler,
so you end with a similar logic scattered across multiple libraries.
Suppose this example:
a.css
b.css
And you create
a_b.css
Now you have these lines:
<h:outputStylesheet name="a.css"/>
<h:outputStylesheet name="b.css"/>
The idea is when a.css or b.css is resolved, it returns a Resource
instance that represents a.css or b.css, but in fact it is holding
a_b.css, so it should be only one link entry rendered on the
response.
regards,
Leonardo Uribe
2014-10-23 3:32 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> On Thursday, October 23, 2014, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>>
>> Sometimes you have a bunch of .js or .css files and you want to group all
>> of them into a single file. To do that, you can create a custom
>> ResourceHandler and redirect the resource requests to the suggested resource
>> that joins all the files or use some library that has already that logic.
>> [...]
>> Some people has already provided solutions.
>
>
> Do you mean something like the combined resource handler in OmniFaces? (
> http://showcase.omnifaces.org/resourcehandlers/CombinedResourceHandler )
>
> Kind regards,
> Arjan Tijms
>
>
>
>>
>> Please note this logic can be made to override jsf.js javascript as
>> well. But from design perspective I don't feel very good about have
>> alternate versions of jsf.js, instead I would like to make jsf.js work
>> even with portlets.
>>
>> It is a fact that JSF is very pluggable from the java perspective, but
>> the fact that you cannot customize the behavior of jsf.js (pass config
>> params on initialization like project stage and others) becomes a
>> problem.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2014-10-22 16:13 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>> > 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
>> >
>> >
>> >