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.
— 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
>>
>>
>>
>>
>>
>>
>>