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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','leonardo.uribe_at_irian.at');>> wrote:
>
> Hi Neil
>
> 2014-10-27 11:38 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','neil.griffin_at_portletfaces.org');>> wrote:
>
>
> On Oct 22, 2014, at 4:27 PM, Edward Burns <edward.burns_at_oracle.com
> <javascript:_e(%7B%7D,'cvml','edward.burns_at_oracle.com');>> wrote:
>
>
> On Tue, 14 Oct 2014 19:30:03 +0200, Frank Caputo <frank_at_frankcaputo.de
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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://
<http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<http://ww.enterprisejavanews.com>*
* JSFCentral Interviews Podcast:
http://www.jsfcentral.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17