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