Over a million developers have joined DZone.

Reusing Front-End Components in Web Applications

· Java Zone

Navigate the Maze of the End-User Experience and pick up this APM Essential guide, brought to you in partnership with CA Technologies

In the Java SE realm, GUI components are based on Java classes with the help of libraries such as AWT, Swing or the newer JavaFX. As such, they can be shared across projects, to be inherited and composed.

Things are entirely different in the Java EE world, as GUI components are completely heterogeneous in nature: they may include static HTML pages, JavaScript files, stylesheets, images, Java Server Pages or Java Server Faces. Solutions to share these resources must be tailored to each type.

  1. Since Servlet 3.0 (Java EE 6), static resources, such as HTML, JavaScript, CSS and images can be shared quite easily. Those resources need to be packaged into the META-INF/resources folder of a JAR. At this point, putting the JAR inside the WEB-INF/lib folder of a webapp will make any such resource available at the webapp’s context root.
    A disadvantage of this approach is that shared resources are also exposed publicly, including JSP that are not meant to be.
  2. An alternative to share resources protected under WEB-INF, which is also available before Servlet 3.0, is to leverage the build tool. In this case, Maven offers a so-called overlay feature through the Maven WAR plugin. This requires both adding the WAR containing resources and dependencies as well as some POM configuration.

    At this point, resources belonging to the dependent WAR artifact will be copied to the project at build-time. Not resources existing in the project may be overwritten… on purpose or by accident. The biggest disadvantage of WAR overlays, however, is that resources have to be packaged in the WAR artifact while corresponding classes have to be in another JAR artifact.

  3. I’ve not much experience in Java Server Faces technology, but it seems sharing pages across different webapps requires the use of ResourceResolver.
  4. Finally, some frameworks are entirely built toward sharing GUI resources. For exaemple, with Vaadin, GUI components are based on Java classes, as for Java SE, thus making those components inheritable and composable. Furthermore, using images can be achieved in a few lines of code and is easy as pie:
  5. Image image = new Image("My image", new ClassResource("ch/frankel/blog/resources/image.png"));

I think Java EE is sadly lacking regarding reuse of front-end resources. Of course, one can choose client-based frameworks to overcome this limitation though they bring their own pros and cons. In all cases, ease of reuse should be an important criteria for choosing front-end technologies.

Thrive in the application economy with an APM model that is strategic. Be E.P.I.C. with CA APM.  Brought to you in partnership with CA Technologies.


Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}