View on GitHub

Weblets

weblets full project mirror

Download this project as a .zip file Download this project as a tar.gz file

Usage of Weblets in a Java/Servlet centric environment

As Weblets originated from a project which was developed for an Ajax and JSF centric book, Weblets has extensive tooling support for JSF , and tries to utilize JSFs internal structures extensively, to ease the configuration and usage.

Weblets itself is not JSF centric, but it has a very strong JSF tooling support besides its generic web framework coverage. Over time it might be possible that other web frameworks could be supported in a similar way where needed.

The base of most if not all web framework technologies is the Java Servlet technology. A very robust frontend controller which can be programmed easily and extensively. The sheer existence of this technology for such a long time with almost no changes and only the enhancement with extension features shows the strong patter in use. It simply was the holy grail of a web framework kernel found very early.

To support most web frameworks in the most generic way, an extensive tooling support for a Servlet environment is provided by Weblets.

The tooling consists of two parts

  1. A Weblets Servlet for Weblets url interception and resource streaming
  2. Generic API Utils classes for loading Weblets from Servlets and Servlet based technologies

Setup

To get Weblets up and running you need a valid Weblets Servlet configuration. Unlike JSF we do not have any automatisms in place. The configuration has to be done explicitly, with a path pattern as trigger for the servlet.

     <servlet>
         <servlet-name>Weblets Servlet</servlet-name>
         <servlet-class>net.java.dev.weblets.WebletsServlet</servlet-class>
     </servlet>


     <!-- The <<<Weblets>>> Servlet mapping must be path based otherwise <<<Weblets>>> will fail! -->
     <servlet-mapping>
         <servlet-name>Weblets Servlet</servlet-name>
         <url-pattern>/weblets/*</url-pattern>
     </servlet-mapping>

More information on the entire web.xml configuration can be found under Weblets Users Guide:Setup Guide

Basic Functions

Introduction

The Weblets APIs follow the general patterns as described in Weblets Users Guide: Introduction to the API Patterns . for further information please follow the link.

Weblets Servlet APIs

The Weblets Servlet APIs are very simple to use, they basically are the two contract functions mapped into a utils class.

    WebletUtils.getResource("org.myapp.html", "/myresource.js")
    WebletUtils.getURL("org.myapp.html", "/myresource.js")

    or

    WebletUtils.getInstance().getResource("org.myapp.html", "/myresource.js")
    WebletUtils.getInstance().getURL("org.myapp.html", "/myresource.js")

It is up to your personal preference which version of the calling methods you use, internally everything is resolved into a singleton call.
The methods themselves are thread save, they should not cause any problems in a multithreaded environment which basically every server is!

Note, we dont have a request object passed down here, to determine the web application context. As already mentioned in the setup guide, we cannot always be sure to have access to the request object.

(A classical situation for instance would be a long running thread which tries to generate some resource urls outside of any request scope)

Some web frameworks bypass it or wrap it or simply add additional behavior via decoration classes. To be as generic as possible Weblets keeps the request object out of the API and tries to get the context name by other means!

Weblets tries to determine the web application context by various means:

  • In a JEE5 environment it uses the Servlet context which has a clearly defined api which returns the web application context name
  • In a pre JEE5 environment you can set a filter in your web xml, which intercepts a request before serving the first resource, then you always can get the web application context internall
  • If both methods fail you can set the context name manually via a web.xml context parameter, this is more or less the final override to enforce a context name

For more information on the three methods see the Weblets Weblets User Guide:Setup Guide .