@Kito: Seems like JSON rendering is related, especially if we need to extend the JS API to be able to handle responses other than partial-response XML documents.
@Leonardo: Thank you so much for mentioning the JAVASERVERFACES_SPEC_PUBLIC-861 issue filed by Werner Punz.
This has been implemented in Mojarra in a vendor-specific manner:
https://java.net/jira/browse/JAVASERVERFACES-3031 <
https://java.net/jira/browse/JAVASERVERFACES-3031>
However, I would be happy to see this standardized.
> On Oct 29, 2014, at 2:55 PM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
>
> Hi
>
> Looking into the issue tracker, I found this related issue:
>
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-861
> Portlets + ajax API
>
> Just to keep it in mind.
>
> regards,
>
> Leonardo Uribe
>
>
>
> 2014-10-28 8:57 GMT-05:00 Kito Mann <kito.mann_at_virtua.com>:
>> Some do these points tie into my proposed enhancement of allowing JSON
>> rendering.
>>
>>
>> On Tuesday, October 28, 2014, Cagatay Civici <cagatay.civici_at_gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I agree that right thing to do is to make jsf.js more flexible.
>>>
>>> Reason why PrimeFaces have its own jquery based implementation is the lack
>>> of extension points.
>>>
>>> For example the request configuration should be customizable to make it
>>> easy to add custom post parameters, request headers to decorate the request.
>>> In addition to decorating, maybe it should allow the caller to implement
>>> certain parts like form serialization, for example in PrimeFaces, we have
>>> the partial submit mode to only serialize the partially executed components
>>> not all the inputs of the parent form. So it is not just decorating but
>>> overriding certain parts like deciding what to update, execute, send as the
>>> caller. If no handler function for a particular part is provided default
>>> implementation should take place.
>>>
>>> Also response handling should allow doing custom parsing of the response
>>> definitely. Again as an example in PF sometimes we just provide JSON,
>>> instead of xml or send a partial markup to only update a certain section of
>>> the component, not whole component.
>>>
>>> Regards,
>>>
>>> Cagatay Civici
>>> PrimeFaces Lead
>>> PrimeTek Informatics
>>> www.primefaces.org
>>>
>>> On Monday 27 October 2014 at 21:21, Leonardo Uribe wrote:
>>>
>>> Hi Neil
>>>
>>> 2014-10-27 13:26 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>>>
>>> Hi Leonardo,
>>>
>>> JSF currently has a means of “decorating” the Ajax URL with the value of
>>> ExternalContext#encodePartialActionURL(String) [1] when the renderer for
>>> h:form writes the following hidden field:
>>>
>>> <input type="hidden" name="javax.faces.encodedURL" value="..." />
>>>
>>> It has been working very well for JSF portlets that use f:ajax, but it is
>>> not the most elegant solution because the value of the hidden field is
>>> unnecessarily submitted in the postback. :-(
>>>
>>> Therefore I would be happy to explore different ways to decorate the Ajax
>>> URL.
>>>
>>>
>>> I see. The point is at the end we start to rely on exotic hacks, when the
>>> right
>>> thing to do is make jsf.js more customizable. The idea could be encode
>>> that
>>> logic into a plugin to jsf.js, so jsf.js call that logic and then get
>>> the right url.
>>>
>>> That would work in different situations, because the portlet could just
>>> provide
>>> a generic logic, and jsf component libraries just consume that logic
>>> indirectly.
>>>
>>> Keep in mind our objective "... the need for the JSF Portlet Bridge to
>>> somehow decorate the jsf.ajax.request() and jsf.ajax.response() JavaScript
>>> function ..." It is pointless to override these two methods if we cannot
>>> force
>>> other third party jsf libraries to make use of them, or at least if we
>>> don't
>>> provide enough flexibility to integrate them together.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> — Neil
>>>
>>>
>>> https://javaserverfaces.java.net/nonav/docs/2.2/javadocs/javax/faces/context/ExternalContext.html#encodePartialActionURL(java.lang.String)
>>>
>>> On Oct 27, 2014, at 1:32 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
>>> wrote:
>>>
>>> Hi Neil
>>>
>>> 2014-10-27 11:38 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>>>
>>> Hi Leonardo,
>>>
>>> When you wrote:
>>>
>>> LU> The problem is jsf.js assume the url (the one on top of the browser).
>>> Most
>>> LU> of the time it works, but the right thing to do is give portlets the
>>> chance to
>>> LU> decide which url should be used, because in fact we don't know how
>>> LU> portlets assemble its urls.
>>>
>>> Are you referring to the URL that jsf.js uses to perform an Ajax request?
>>>
>>>
>>> Yes, one way or another there should be some decoration over that url.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> Best Regards,
>>>
>>> Neil
>>>
>>> On Oct 24, 2014, at 1:16 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
>>> wrote:
>>>
>>> Hi
>>>
>>> Yes, I agree with you that we need a way to customize how jsf.js behave,
>>> rather than override jsf.js. I just wanted to notice the issue, because
>>> with JSF 2.2 as is, the only option you have right now to make portlets
>>> work is provide a custom jsf.js through a custom ResourceHandler.
>>>
>>> Going back to the original problem, what do we need in jsf.js to be
>>> extensible enough? "In theory" the best scenario would be than
>>> components written with JSF should work in servlet and in portlet
>>> mode without any changes. That should be our main goal (in my
>>> humble opinion).
>>>
>>> The problem is by its design, a portlet should wrap jsf, so every request
>>> should go first to portlet engine so it can be decoded properly and then
>>> resolved to jsf. In the same way, every generate URL by JSF should be
>>> encoded properly to be used by portlet engine. We have:
>>>
>>> - Resource requests (resolved by ResourceHandler)
>>> - Page requests (load a page by first time, or GET navigation)
>>> - Postback or Ajax requests.
>>>
>>> Each one of these requests requires to be done against a generated URL.
>>> So, the first rule we must preserve to be portlet-friendly is you should
>>> never
>>> ever burn a URL in the code, because portlets needs to override that.
>>>
>>> Usually resource urls are encoded in the page, so we can override them
>>> from
>>> server side, but that is not always the case, because some complex
>>> javascript
>>> components require generate resource urls dynamically (there is no js
>>> utility
>>> to do that in jsf right now).
>>>
>>> Page urls are usually generated on the server, so it applies more or less
>>> the
>>> same. But if you take a look at our renderers, the part that provide the
>>> url
>>> always change. If we have added client window, we should update the
>>> renderer of h:link to add it. The same applies to faces flows. But the
>>> same
>>> applies to other JSF libraries!. It is not possible to generate an url
>>> just
>>> like
>>> h:link does without replicate step by step what the renderer does.
>>> Shouldn't
>>> that logic reside in just one method?
>>>
>>> Postback or ajax requests needs some attention in portlets. First of all,
>>> it
>>> is
>>> necessary to:
>>>
>>> 1. get the ViewState to be changed.
>>> 2. get the url to send the ajax request.
>>> 3. perform the request.
>>> 4. portlet intercept the request, decode it and forward it to the target
>>> jsf application
>>> .....
>>>
>>> The problem is jsf.js assume the url (the one on top of the browser). Most
>>> of the time it works, but the right thing to do is give portlets the
>>> chance
>>> to
>>> decide which url should be used, because in fact we don't know how
>>> portlets assemble its urls.
>>>
>>> What's the ideal behavior?. When the page is loaded by first time, jsf.js
>>> is
>>> loaded and an <script> tag is executed that contains the initialization
>>> params for jsf.js, like project stage, extension points and so on. In that
>>> way,
>>> portlets has the chance to provide its own logic and do whatever they
>>> want,
>>> (set the target url properly, add additional headers to the ajax request,
>>> ....)
>>>
>>> @Neil: Am I right? or do you think portlets needs something else from JSF?
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2014-10-23 16:50 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> ___
>>
>> 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
>>