This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RE: Using jQuery with JSF 2.0's resource

 
H G Brown
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I am struggling to get jQuery UI (1.8.6) library integrated with JSF 2.0 (Facelets) using the resources functionality. I have re-factored the index.html from the standard jQuery UI library to use JSF tags in the head of my page as follows:



I then include the details of the index.html which comes with the jQuery UI download (showcasing the different components) in the body of my page. All the elements are displayed and function correctly (Accordian, Autocomplete etc) except that none of the images are displayed (e.g. the Framework Icons are all just empty gray boxes, there is no prev/next images on the datepicker etc).

If I forgo the JSF tags above and include the css and scripts using standard html tags, i.e.


Then everything works and the images are displayed as expected.

Has anybody managed to get this working? Any help or pointers in the right direction would certainly be appreciated.
 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Try omitting the library="..." and add the prefix to the name= attribute. There have been some
issues raised in the primefaces forum on this, and this will help (I hope), although I cannot say
why.

Regards,
Brendan.
 
H G Brown
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Brendan

Thanks very much for your help and time. I can confirm that your solution works 100% though I can't really explain why either.

Best Regards,
Henry
 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm glad it worked, I suppose it's pretty obvious really, library= simply doesn't work with
hutputScript with Mojarra 2.0.3. Or maybe it's less simple than that! Nothing would
surprise me.
 
Ren Rem
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know I'm a bit late to the party, but I think I stumbled onto the cause of the problem.

I have been working with a sample app, doing a crash refresher course on JSF 2.0, and one of the exercises calls for including a CSS (specifically the h:outputStylesheet tag). Well, the first time through that exercise, it worked fine using the "library=" setting, but in setting that exercise up again (under a different project name) I get the same results as the OP. When looking at the Page Source in the browser, it turns out that the resources directory did not get added to the target WAR.

Curious as to why it worked the first time by following the exercise instructions, but not the second time under a different project name, I dug into the three files that could be the culprit. After eliminating home.xhtml and the styles.css, I found the culprit in the pom.xml file for the project. I've included the portion of the pom.xml which specifies the structure of the target WAR:


This is what will be used if your project is called "helloworld" and you've set up a CSS directory under /src/main/resources in the project. (I'm using Eclipse).
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18094
48
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure I followed that. Anything in src/main/resources will automatically be copied to its equivalent directory location in the target WAR. An explicit copy is only required if you are doing substitutions.

One hidden "gotcha" when using advanced JSF tag libraries such as RichFaces and PrimeFaces is that these tag libraries themselves pull in jQuery to do their behind-the-scenes work. Problem is, the copy pulled in is often very ancient compared to the version you want to use, so you have to explicitly override what your tag library will be fetching.
 
Ren Rem
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using Maven to manage the project, the src/main/resources directories were not copied by default. Maven only copied the resources directory into the target WAR when explicitly directed in the pom.xml ... and this was using straight JSF 2.0 (not Richfaces, Primefaces or Icefaces). This is with Maven 2.2.1.

If I wasn't using a Maven-generated project, and simply had a "built-from-scratch" project, then the resource folders would have been included in the WAR. I hadn't seen anything like that before (not in the six years I've been using Faces - but that's probably because I normally build the pom.xml based on the project I'm actually working with. This time, in doing my refresher, I took a short-cut and ended up with the same symptoms as the OP (which is how I found the OP five years after the fact.)

When deploying the Maven-produced WAR to Tomcat, there was no resources folder in the webapp tree at all - and the reason I looked at the directory of the deployed webapp was because when I looked at the page-source of the home.jsf, JSF put in a src="RES_NOT_FOUND" message in the rendered home.jsf where the path to the Resource file should be.

Basically, what I'm saying is that when my pom.xml directive is correctly configured, the library= attribute works just fine.

What the OP should check is to see if the deployed webapp directory actually has the resources folder included - and if not, make sure that it's included in the project tree AND that any build files (such as Maven's pom.xml) are configured properly.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18094
48
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you have
and

in your POM? Because I've been doing this for years with no trouble.
 
Ren Rem
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's EXACTLY what I'm getting at ... sorry to be so confusing ... a <plugin> tag which specifies the resources directory HAS to be present AND correctly configured in order for Maven to actually include the resource directory in the target WAR. If it's not present, or is not configured correctly for the OP, that would explain why the library= attribute is not working correctly and why he had to use the fully-qualified path to the resource.

And the only reason I stumbled on it is because I did a cut-and-paste of a pom.xml from another project. Instead of a maven-war-plugin, I'm using a maven-resources-plugin for the WAR build. In my case, the plugin included the name of the other project in the <outputDirectory> for the target. And neither tag is included in the pom.xml when I do a "mvn archetype:generate ..." so it has to be put in by hand - something that is easily overlooked since project set-up is not an everyday task.

If neither a maven-war-plugin or maven-resources-plugin is present in the pom.xml (or another plugin which specifies including the resources) - then there will be no resources directory in the WAR or the deployed webapp tree and the library= attribute won't work.

In my case, the library= attribute works using the maven-resources-plugin *when* I configured it correctly.



 
Tim Holloway
Saloon Keeper
Pie
Posts: 18094
48
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Every POM should be constructed according to what type of package (product/artefact) it is expected to produce. The default is JAR, but building a WAR using the JAR package type only works because a WAR is a type of JAR. The JAR rules, however, don't do all the dirty work that's needed to make a workable WAR (for example, copying the resources), so it's more appropriate to tell Maven to use the WAR packaging rules instead.

Maven will often pull plugins in automatically to help with the build process, but adding explicit plugin information allows you to use a different version than the (often outdated) default plugin. Plus it allows you to customize the plugin's behavior. For example, in Maven 2, the java-compiler-plugin would compile code according to Java version 1.3 specs by default. In order to get the goodies that were added to later compilers, you should override that using the configuration sub-element of the plugin element for maven-compiler-plugin.

Then there are the optional plugins. I build a lot of WARs to be installed on Red Hat Linux, and I use the RPM plugin to build the WAR and then make an RPM installer package based on that. I have a plugin that deploys releases to my site Nexus repository. And so forth.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic