Skip to main content

JSF 2 How to resolve Resource URLs in UIComponents

5 replies [Last post]
razib
Offline
Joined: 2010-01-28
Points: 0

Hello,

In JSF 2, a great EL shortcut was introduced to get the url for resources using #resource['/library/image.jpg'].

I would like to get the URL of an image inside a custom component using an equivalent java syntax. The image resource lies inside META-INF/resources/library, and I couldn't find any convenient way of referencing the path of image when writing an "img" tag inside my UIComponent.

I have been looking around facesContext.getApplication().getResourceHandler(), but resource handler has no such method to find a resource in META-INF/resources.

Please let me know what is the best method of resolving such resources inside a component.

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vesuvius
Offline
Joined: 2007-06-02
Points: 0

Well, I only know a little bit about Wicket and I really cannot compare the two frameworks. I just think that if JSF makes it at least as easy and efficient to do everything with pure Java (e.g. manipulate the component tree), then the Wicket guys won't be able to say anything against it.

I like the concept of Wicket. I like Java. Pure Java. I'm tired of superfluous dependency injections, superfluous annotations, superfluous interceptors, superfluous mocking. I mean, I know that these are necessary and useful and I'm willing to use them, but only wherever it's really appropriate. I don't want them to take over everything. Sometimes I find myself contemplating whether annotations and reflection are the new XML. There was a time when reflection was being discouraged. Now it's everywhere. Everywhere!

I'd prefer to program with interfaces, instead of annotations, [i]wherever appropriate[/i]. I'd like to keep things simple and pure. And I think that's what most people like about Wicket. Pure Java. Simplicity.

If JSF can do that as well as Wicket, then the Wicket guys won't have anything to say. I know JSF can manipulate the component tree programmatically. I just don't know how it compares with Wicket in that department. Maybe it's as good, or maybe not. It's in my "to do" list to read a book about Wicket and to toy with it a little bit. I want to see how it "feels".

JSF is much better at defining the presentation layer with [i]markup[/i]. That's great. Just make the programmatic part as good as (or better than) Wicket's, and there will be no argument which framework is better.

Ed Burns

>>>>> On Sun, 28 Mar 2010 02:42:16 -0700 (PDT), webtier@javadesktop.org said:

R> In JSF 2, a great EL shortcut was introduced to get the url for
R> resources using #resource['/library/image.jpg'].

R> I would like to get the URL of an image inside a custom component
R> using an equivalent java syntax. The image resource lies inside

Your request indicates the need for a much simpler way to do this. It
*can* currently be done (see below), but I want you to please add an
issue to the https://javaserverfaces-spec-eg.dev.java.net/ issue tracker
requesting this feature (I've given you permission to add it).

R> I have been looking around
R> [i]facesContext.getApplication().getResourceHandler()[/i], but
R> resource handler has no such method to find a resource in
R> META-INF/resources.

What I'm about to say will feed the trolls who say JSF is too complex,
so let me start by saying we'll add something like this to satisfy your
request (this doesn't exist yet, but is trivial to implement)

facesContext.getApplication.getResourceHandler().getRequestPath("image.jpg",
"library");

In lieu of this, you must do the following:

ResourceHandler rh = facesContext.getApplication.getResourceHandler();

Resource r = rh.createResource("image.jpg", "library");
rh.getRequestPath();

I know, it's horribly complex and would by much simpler in Wicket, but,
hey, at least you can do it. Oh, wait, Wicket doesn't have a resources
feature. Hmm.

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

razib
Offline
Joined: 2010-01-28
Points: 0

Thanks Ed, the solution you suggested works.

I'd like to add the request for getRequestPath(..) method to the issue tracker, however I am getting a permission error when I goto the page:

[i]Your account does not have the "Project Page - View" permission needed for you to access the page you requested[/i]

Could you please grant me the necessary permission to access the page.

JSF 2 is quite elegant, and imho it does things better than wicket. JSF technology has lots of potential, and I hope it will continue to grow and evolve like it did in JSF 2.

Ed Burns

>>>>> On Mon, 29 Mar 2010 15:08:27 -0700 (PDT), webtier@javadesktop.org said:

R> Thanks Ed, the solution you suggested works.

R> I'd like to add the request for getRequestPath(..) method to the
R> issue tracker, however I am getting a permission error when I goto
R> the page:

R> Could you please grant me the necessary permission to access the
R> page.

Yes, I have done so.

Ed

--
| edward.burns... | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

razib
Offline
Joined: 2010-01-28
Points: 0

I am running across a possible bug in Mojarra implementation of JSF2.

When resources are declared as dependencies for a component using the @ResourceDependency annotation, EL expressions are parsed correctly in resource CSS files, but it is not parsed in Javascript files. For instance, if you use an EL expression inside a CSS file /META-INF/library/style.css, that is resolved correctly.

But EL expressions are not parsed in a Javascript resource dependency e.g. /META-INF/library/script.js

Let me know what you think...