JSF 2.0 New Feature Preview Series (Part 2.3): Resources

This is the fourth blog in the JSF 2.0 New Feature Preview Series.
The previous entry covered the new resource API. This will be
the last part of the Resources portion of this series and will cover
leveraging the resource handling from the expression language.

A resource can be reference via the EL using the following syntax:
  • #{resource['<resource name>']}
OR
  • #{resource['<library name>:<resource name>']}
Where and are both literals that map to a resource within the application.

If using Facelets, it would be possible to output the resource URL
directly without using a component:
  • <a href="#{resource['header.jpg']}" />;
The resource expression can also be used in h:graphicImage:
  • <h:graphicImage value="#{resource['corp:header.jpg']}" />;
That said, I do think the EL expression syntax is somewhat limiting (due
to limitations of the EL itself). Consider theming. An application could
have several themes partitioned as different resource libraries. In this
situation it would be impossible to overload the library value of the expression
without a custom ResourceHandler implementation.

However, it is possible to eschew the value attribute on h:graphicImage and
specify a library and name attribute that accept expression to resolve the
library and resource name dynamically.

Keep an eye out for the next blog entry where I'll cover the expanded
event system.
Comments:

Ryan,

Glad to see you made a post. Great information!

I wish you would post more often though :-) The online info about 2.0 is so little. I myself am eagerly awaiting the release of 2.0 with full docs, so any information you can provide about the new features would be greatly appreciated no matter how trivial they are.

Thanks,
RD

Posted by RD on June 23, 2008 at 10:05 AM PDT #

Sorry it's been quiet as of late. We've been working hard on the 2.0 implementation. I've got three other blogs planned this week, so stay tuned.

Posted by Ryan Lubke on June 23, 2008 at 10:13 AM PDT #

[Trackback] We all know that Ryan Lubke is a top notch engineer, but did you also know he's a solid technical writer? Ryan has been posting plenty of really useful content on his blog about JSF 2.0, including the series on new features in JSF 2.0. This entry summ...

Posted by Ed Burns's Blog on June 26, 2008 at 07:00 AM PDT #

Ryan
Thank you very much for sharing this info. Good to see that lots of developments are happening around JSF.

One humble suggestion. I assume that one major drwback of curretn JSF is the lack of support for packaging jsp/xhtml in separate jars. I'e seen many application which invoves lots of business modules, need to package each module separately. It means that backing bean,resourcebundle and xhtml/jsp's needs to be packaged separately for each module - effectively as separate jar's. I happened to see the documentation for a4j:loadStyle and a4j:loadScript from JBoss RichFaces. Curious to know whether JSF 2.0 has any similar startegy for jsp/xhmtl as well.

Unfortunately by defalut, there is no support to load jsp if packaged them in separte jar file (this jar is available in web-inf/lib) instead of web application folder directly. I can see this kind of features with other frameworks like Tapestry.

Thanks
Jobinesh

Posted by Jobinesh on June 27, 2008 at 04:35 PM PDT #

What about dynamically created resources? If I have a chart component which generates a JPG on the fly, how do the new resources apis help me?

Posted by Andrew on July 22, 2008 at 08:39 AM PDT #

Either continue with how you're currently doing it, or provide a custom ResourceHandler to cope with dynamic resources.

Posted by guest on July 22, 2008 at 08:48 AM PDT #

I'm trying out 2.0EDR1 on Tomcat 6.0.16. Using the provided numberGuess sample WAR, resources don't appear to be referenced correctly, if the context path name is "/guess" (i.e. same as the FacesServlet relative path mapping)

Both the validator.js and the Duke image are generated as absolute links (/guess/javax.faces.resource/....), but they need an additional /guess, since the FacesServlet is mapped to a webapp-relative path /guess.

However, this doesn't happen if I use a different name for the context path (say, "/numberGuess"). Then links are correctly generated as absolute links (/numberGuess/guess/javax.faces.resource...). Is this a bug?

Posted by Rory on October 14, 2008 at 04:58 AM PDT #

Thanks for the report. I've logged:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=815

Posted by Ryan Lubke on October 14, 2008 at 05:19 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

user12615560

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today