Ryan Lubke's Blog

« JSF 2.0 New Feature... | Main | Trinidad+Mojarra »

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

Saturday Feb 16, 2008

This is the third blog in the JSF 2.0 New Feature Preview Series.
The previous entry covered packaging of resources. Now we'll cover the APIs that back
this feature. Keep in mind that none of the features described are final, and may
change, but this is a good opportunity to show the features as they exist now and
illicit feedback.

Two new API classes are available for Resource handling:

javax.faces.application.ResourceHandler [1]
javax.faces.application.Resource [2]

The Resource class is pretty straight forward. This class is basically a representation
of an actual resource such as an image or style sheet. It also provides methods
to help the ResourceHandler serve the underlying resource.

The ResourceHandler class is responsible for both creating Resource instances as well
as serving said resources to the user-agent.

So how does a developer leverage these classes? Well, in general, a developer
will obtain the ResourceHandler (FacesContext.getApplication().getResourceHandler())
and create one or more Resource instances (ResourceHandler.createResource()).
Then the Resource can be encoded (Resource.getRequestPath()) that will generate
a special URI for serving it.

For example, let's say a Renderer is writing out an HTML img tag. The result
of calling Resource.getRequestPath() will be the value of the img tag's src attribute, and
when rendered to the browser would look something like:

<img src="<context-root>/javax.faces.resource/<resource-name> +
[?ln=<library-name>][&loc=<locale-prefix>][&v=<version>]

Let's break this down. As per the previous blog regarding packaging, there are several
bits of meta-data associated with a Resource. These are its library name, locale, and
version (all optional). If a Resource has any of these, they will be encoded in the URI.
If any of the values change, such as the locale prefix or a version increment, the change
will be present in the URI and because the URI differs the user-agent will request the
new resource automatically.

One might be wondering how the resources are served. Past attempts as resolving this
issue have used a PhaseListener, or a Filter, but the neither are used in this case.
The solution, to avoid having to specify additional artifacts in the faces-config or web.xml,
is to have the FacesServlet leverage the ResourceHandler directly. Specifically, the
FacesServlet will, on each request, ask the ResourceHandler (by invoking
ResourceHandler.isResourceRequest()), if the current request is a Resource Request
(i.e. the request URI contains the identifier /javax.faces.resource), and if it is determined
to be a Resource Request, the FacesServlet will call handleResourceRequest() on the
ResourceHandler to serve the resource. If the request is not a Resource Request, the
standard JSF lifecycle processing will occur.

It should be noted that when serving resources, the ResourceHandler will ask the Resource
instance if the user-agent requires updating, so that if the resource hasn't changed, a 304
can simply be returned to reduce the load of the network.

Also, the behavior of Mojarra's implementation of ResourceHandler will differ depending
on the current value for ProjectStage. If the current stage is Development, any request
to the ResourceHandler to create a Resource will result in the system computing the
paths and searching for the resource. Since this process is expensive, Mojarra will, when
the ProjectStage is Production, cache the resource meta-data to lessen the load on the
system. By default changes will be checked for every five minutes and if changes are
found, the cache is dumped so that it will be rebuilt with the new changes that are
present. I wanted to point out that when developing a project and you want to see
any resource additions picked up right away make sure you've set the ProjectStage for
Development.

Finally, like other artifacts within JSF, if the default implementation doesn't suit your needs,
you can completely replace or decorate the implementation with functionality that meets
your requirements.

[1] Raw source for javax.faces.application.ResourceHandler
[2] Raw source for javax.faces.application.Resource

[8] Comments

Like this post?

Posted at 08:47PM Feb 16, 2008 by rlubke in Sun
Tags:

Comments:

Hello and thank you for the JSF 2.0 introduction.

I am glad JSF 2.0 introduces Resources feature. I would like to ask if you are thinking about some component or something that will manage resources for whole page, i.e. resources of all used components placed in html/head context.

Image I have JSF library mylib that introduces two components mycom1 and mycom2. Both components use same css resource (mylib.css) and each component brings itself javascript resource (mycom1.js and mycom2.js). On my web page I use mycom1 3 times and mycom2 5 times. But I want my web page references resources mylib.css, mycom1.js and mycom2.js - all of them just once.

I can imagine JSF component headResources (and some API) my components can communicate to. E.g.:
--
<html>
<head>
<title>My Title</title>
<h:headResources/>
</head>
<body>
<my:comp2/><my:comp1/>
<my:comp2/><my:comp1/><my:comp2/><my:comp1/><my:comp2/>
</body>
</html>
--

Or something better. Page is also JSF component and included sub-components can communicate with parent components. And it is possible to add html head facet to page component. E.g.:
--
<h:page>
<f:facet name="head">
<title>My Title</title>
</f:facet>
<f:facet name="body">
<my:comp2/><my:comp1/>
<my:comp2/><my:comp1/><my:comp2/><my:comp1/><my:comp2/>
</f:facet>
</h:page>
--

Do you think about such resource management? If so which solution do you think about.

Posted by Libor Kramolis on February 17, 2008 at 02:23 AM PST #

Yes, the EG has been working hard on solving this issue. In fact we'll be implementing the proposal in the next week or so. Once it's complete, we'll be blogging about it, so stay tuned!

Posted by Ryan Lubke on February 17, 2008 at 05:23 AM PST #

A very useful feature! JSF 2.0 will be a big step in JSF development!

Posted by _rogerio_ on February 17, 2008 at 06:54 AM PST #

And what about resource dependencies? For example, some insertable facelet needs prototype.js and some own componentbase.js, other facelet needs prototype.js, componentbase.js and component.js. Will be there a possibility to place the scripts in correct order?

Posted by Henady on March 29, 2008 at 03:21 AM PDT #

Part 3 please :-)

Posted by Behrang Saeedzadeh on April 04, 2008 at 07:51 AM PDT #

> to avoid having to specify additional artifacts in the faces-config or web.xml,
> is to have the FacesServlet leverage the ResourceHandler directly. Specifically,
> the FacesServlet will, on each request, ask the ResourceHandler if the current
> request is a Resource Request and if it is determined to be a Resource Request,
> the FacesServlet will call handleResourceRequest() on the ResourceHandler to serve
> the resource.

This is a great solution! I absolutely agree that we want to stop using phase listeners and filters for this purpose.

BTW, while you are adding checks, could you also add a check for "isPostback()". I cannot tell you the number of times I have needed to know whether I am dealing with an initial request or a postback. Right now you have to check for a request attribute, which is a frail approach.

Posted by Dan Allen on May 12, 2008 at 12:48 PM PDT #

Hi Dan,

There is an isPostBack() method in 1.2 on the ResponseStateManager implementation -> FacesContext.getRenderKit().getResponseStateManager().isPostBack(FacesContext).

Posted by Ryan Lubke on May 12, 2008 at 04:04 PM 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...