+1 Leonardo. Can you add an issue to the issue tracker? I think pretty much
every non-trivial app would want need this.
On Thu, Oct 23, 2014 at 11:42 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> 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
> >> >
> >> >
> >> >
>