Working towards RichFaces / PrimeFaces compatibility

[lfryc]

Cagatay Civici wrote:
@Brian, if you are open to discussions for compatibility between Rich and Prime, I'm ok with that. I guess all the problems I heard are because of both libraries using jQuery, I think that could be fixed if we include jQuery once, hopefully the same version 

Yes, this would solve one of compatibility problems. Question is how to achieve that.

There is solution forcing JSF to do not render resource link by providing resource name/library which should not be rendered.

But it is quite fragile, tied to impl, thus it would be great if the resource loading would get much more attention in JSF spec (there is no way how to control resource loading on high-level currently).

But the intermittent solution above could be managed and supported in framework.

[lfryc]

Bernard Labno wrote:
How about putting jquery in the same folder in both rich and prime jars? 
library="jquery.com" name="jquery.js"

I was thinking about the same, but it is not deterministic which resource will be loaded from classpath.

Then in case of different versions in both JARs, the resource which will be provided to user may differ.

Bernard Labno wrote:
Or let's even create separate project which produces "jquery.jar" and it could contain all the jquery related resources (css,js,img).

It would be great to work with jQuery team on packaging their deps in Maven repository.

[lfryc]

Btw RichFaces Resource Mapping [1] can force resource handler to serve only one version of jQuery:

something like:

jquery.js=#{facesContext.externalContext.requestContextPath}/javax.faces.resources/jquery.js
primefaces:jquery/jquery.js=#{facesContext.externalContext.requestContextPath}/javax.faces.resources/jquery.js

The same way user can provide own jQuery.

[1] http://docs.jboss.org/richfaces/latest_4_X/Developer_Guide/en-US/html/chap-Developer_Guide-Advanced_features.html#sect-Developer_Guide-Advanced_features-Resource_mapping

[chelachen]

1、 web.xml add:

<context-param>

    <param-name>org.richfaces.resourceMapping.enabled</param-name>

    <param-value>true</param-value>

</context-param>

<context-param>

    <param-name>org.richfaces.resourceMapping.mappingFile</param-name>

    <param-value>META-INF/custom-mapping.properties</param-value>

</context-param>

2、custom-mapping.properties：

jquery.js=#{facesContext.externalContext.requestContextPath}/javax.faces.resources/jquery.js

primefaces:jquery/jquery.js=#{facesContext.externalContext.requestContextPath}/javax.faces.resources/jquery.js

3、Use like:

<p:dialog  visible="true">

    <rich:calendar/>

</p:dialog>

rich:calendar is still broken..

Do I miss sth?

[josh68]

Would like to hear a response to this, as well. A good ultimate goal would be to allow decoupling of jquery.js and jquery-ui.js from both RF and PF, so that they can be updated separately (maybe with some breakage incurred) and loaded from CDNs. The solution of having to upgrade taglib jars just to get the latest 3rd-party js libs seems unsatisfactory. Thanks.

[lfryc]

Hey guys, just note here is the blog which describes RichFaces Resource Mapping in detail:

http://rik-ansikter.blogspot.com/2012/02/re-routing-jsf-resource-requests-with.html

Note also that Resource Mapping has been simplified significantly (no more context switches needed in 4.2), updated state can be found in blog, but docs changes coming soon!

[lfryc]

chelachen wrote:

rich:calendar is still broken..

Do I miss sth?

Hi cheelachen, unifying jquery.js version is only one step required for compatibility, there are other points which would require deeper work:

• specific versions of RichFaces and PrimeFaces could be tested with different versions of jQuery
  • using different version could break compatibility
• but also other side effects could be observed
  • usage of jQuery plugins of different version
    • note that RF does not use jQuery UI itself ATM
    • only jQuery plugins (position, mousewheel, hotkey) are used
  • custom library-specific (RF/PF) code collisions
  • skinning collisions (like skinning standard controls)

You guys are pioneers in trying out compatibility of our libs!

We would appreciate your experience and insight to the problem.

[lfryc]

Josh Schneider wrote:

.. A good ultimate goal would be to allow decoupling of jquery.js and jquery-ui.js from both RF and PF, so that they can be updated separately (maybe with some breakage incurred) and loaded from CDNs. ...

With RichFaces Resource Mapping, you can do exactly the job - replace library specific javascript resource -, be sure to checkout blog referenced above.

[josh68]

One issue is that PrimeFaces concatenates jquery core and (parts of the) jquery ui, so a reference to jquery.js is different for RichFaces and PrimeFaces. My vote for both libraries would be to either use vanilla jquery core (already the case) and jquery ui (not currently the case), and if something needs to be added for particular functionality/theming of components, that's done in separate files as overrides or additions. That wish may be difficult to achieve, if, as in PrimeFaces' case, the custom components are really just leveraging the UI, but not simply wrapping native jQuery UI components. I've seen that's a future goal for RichFaces, which is great, but unless both projects adopt that same strategy, the combination will remain tricky or a heavily manual process.

To be a little more concrete about it, I can't just replace PrimeFaces jquery with a combination of CDN-served jquery core and jquery ui - things break. And the fact that they concatenate those two libraries (or parts of them) by default means that you can't just use RichFaces resource mapping to solve the problem. My solution, so far, is to have RichFaces point to PrimeFaces' jquery.js, for both jquery.js and jquery-ui-core.js. But in my project, for now, I also have to edit that PF version of jquery.js to include some vanilla jquery ui components. I can't, for example, use plain jquery ui dialogs (instantiated from my script files) with only PF's version of jquery.js. They've written their own dialog component, so I have to use p:dialog to get things to work, or else add modules to the PF jquery.js.

BTW, if RichFaces ever updates its components to be fully jQuery-UI-compatible (as is proposed), i probably wouldn't be looking at combining the two libraries.

[lfryc]

Hi Josh,

thanks for great analysis, I haven't been aware of fact that PrimeFaces packages jQuery+jQueryUI together.

But then you could use PF version, and point RichFaces's jquery.js to PrimeFaces package jQuery+jQueryUI, have you tried that?

[jotraverso]

Hi all,

I've been trying to put this working on my EAR app. I've spend on this more hours that I can with no result. The main problem that I have is on loading jquery.js resource when i put Richfaces 4.2.0.Final toghether with Primefaces 3.2.

I'm not able to configure resource mapping for load my alternative version of richfaces jquery.js resource, the only config that (partially) works is load from http://code.jquery.com/jquery-1.7.1.js with this

jquery.js=http://code.jquery.com/jquery-1.7.1.js

Please, could some caritative soul give a working proof of concept for resource mapping?

I have yet view and review the article from above (thanks LukášLukáš Fryč) but I still confused about the correct location for my alternative resource, because I tried so many locations and only get broke the resource resolution, but not get to work as I think/wish.

Another point is that, when I try to use resource mapping file for primefaces's jquery resolution, resolution gets broken, I was trying this

primefaces\:jquery\jquery.js=jquery-alternative.js

Thanks in advance.

[lfryc]

Yeah, as I have commented in the blog, this feature had ugly issue which prevented to use whatever location you would like.

It is corrected in 4.2.1-SNAPSHOT and will be released as part of 4.2.1.CR1.

[lfryc]

Btw as Jorge pointed out (thanks!), he published proof of concept of interoperability here:

https://github.com/jotraverso/Richfaces-Primefaces

Let's check it out if you don't want to start from green field. :-)

[lukascz]

Thanks for these hints. It really helped.

However, now I'm facing with the same problem if the richfaces component is defined within primefaces one.

For example, in this case calendar will not pop up:

<p:tab  id="links" title="#{text['tab.header.links']}">

  <rich:calendar />

</p:tab>

If the calendar is outside of p:tab, then it's working fine.

Any idea why?

[lukascz]

I just found out that calendar will not pop up only if the corresponding tabview has some effect, e.g.

<p:tabView effect="slide">  

     <p:tab  id="links" title="#{text['tab.header.links']}">

            <rich:calendar />

         </p:tab>

...

</p:tabView>

If no effect is set up, then rich:calendar will pop up just fine