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
>