Hi
I just wanted to note an issue that has been around for some time and
it is related. 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.
It would be great if JSF by default could handle that "alias" logic.
If the project stage is Development then load the uncompressed files,
but if it is Production use this compressed javascript. That would
improve performance and has been mentioned in the past. Some people
has already provided solutions.
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
>
>
>