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 (mailto: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 (mailto:leonardo.uribe_at_irian.at)> wrote:
> >
> > Hi Neil
> >
> > 2014-10-27 11:38 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org (mailto: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 (mailto: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 (mailto: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 (mailto: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 (mailto: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 (mailto: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 (mailto:neil.griffin_at_portletfaces.org)> wrote:
> >
> >
> > On Oct 22, 2014, at 4:27 PM, Edward Burns <edward.burns_at_oracle.com (mailto:edward.burns_at_oracle.com)> wrote:
> >
> >
> > On Tue, 14 Oct 2014 19:30:03 +0200, Frank Caputo <frank_at_frankcaputo.de (mailto: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 (mailto: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