3

I would like to ask you a question, which is related to another question I asked some times ago (without answer unfortunately :( )

Imagine that your project is divided into several web-apps. You also have many shared resources (JS, CSS, images). The idea is to avoid duplications in each web-app, as you will be forced to synchronize your changes among all the web-applications.

So it seems better to have these resources on a single place.

If I have a look on the Richfaces project, all their resources are managed by JSF. For example, the <rich:calendar> component displays a little icon. If we look the HTML code for this image, we see that the src attribute refers to a jsf link, not a .png directly:

<img src="/richfaces-demo/a4j/g/3_3_3.Finalorg.richfaces.renderkit.html.iconimages.CalendarIcon/DATB/eAH7cW0fw6znAA8XBA4_.jsf"
    style="vertical-align: middle" id="j_id354:j_id355PopupButton" class="rich-calendar-button " alt="">

I see the following advantages of such approach:

  • Include the resources in a classical library (i.e. in a JAR), which eases the deployment on Eclipse;
  • Allow to generate dynamic file (i.e. CSS or JS that only contain the required properties);
  • Allow the inclusion of only the required resources (for ex. we will not load a CSS file if it is not required by a component on the page).

Regarding my application, I will only need the first point, but it is really important to me (cf. my other related question on SO).

The main drawback of this solution is that the browser will not be able to cache the resources as they are considered as JSF requests. Also, each of these requests will have to go through the whole JSF lifecycle, which can be a performance issue if the number of resources in the current page is important...

Questions

Thanks.

Community
  • 1
  • 1
Romain Linsolas
  • 79,475
  • 49
  • 202
  • 273

1 Answers1

1

Yes, it is definitely a good idea to put shared resources in a separate project which is to be included as a JAR in the main web applications. We however use a simple @WebServlet for this which serves the static resources straight from the classpath, along with cache and gzip support. We don't delegate this job to the JSF, we just utilize JSF resource management which in turn fully transparently calls the servlet by URL.


Allow to generate dynamic file (i.e. CSS or JS that only contain the required properties)

That's also doable by using a specific URL and then passing the filenames of the separate resources as query string. The static resource servlet will then do the nasty work of reading multiple resources into a single response.


Allow the inclusion of only the required resources (for ex. we will not load a CSS file if it is not required by a component on the page).

That's to be done by @ResourceDependency annotation. E.g.

@ResourceDependency(library="css", name="specific.css")
public class CustomComponentWithCSS extends UIComponentBase {
    // ...
}

We use a modified version of this FileServlet which is altered to get the resource from the classpath instead of from local disk file system. Also, range support is removed (since RandomAccessFile can't directly operate on classpath resources). Further we have added a check if the current stage is development or not and if not, then serve a minified version of CSS/JS instead which is put in a different path.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • That seems a quite good idea. Unfortunately, we are still using **JSF 1.2**, so no `@WebServlet` nor `@ResourceDependency` are usable :( – Romain Linsolas May 11 '11 at 12:49
  • Well, then you have to clutter your webapp's `web.xml` with a `` entry. The servlet itself can just be kept in the JAR. – BalusC May 11 '11 at 12:50
  • I'm not sure to get your point regarding this modification of the `web.xml` file... – Romain Linsolas May 11 '11 at 14:24
  • You can just keep the static resource servlet in JAR file. You can just use `` mapping in the webapp's `web.xml` to reference this static resource servlet, exactly like as you do for the JSF `FacesServlet`. – BalusC May 11 '11 at 14:25