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?
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
>>
>>
>>
>>
>>
>>