Home of: [Atelier "FUJIGURUMA"] >> [PageMixer hosted by SourceForge.net]

SEE "For Readers of English Version",
or Japanese version of this page

Overview of PageServlet

This section explains overview of PageServlet provided by PageMixer.


Class names

In this tutorial, abbreviated class names are used. Complete names are shown below.

Classes of PageMixer framework

NotationFull name
ConsumerContext jp.ne.dti.lares.foozy.pagemixer.mixer.ConsumerContext
Filter jp.ne.dti.lares.foozy.pagemixer.mixer.Filter
PageEntry jp.ne.dti.lares.foozy.pagemixer.page.PageEntry
PageServlet jp.ne.dti.lares.foozy.pagemixer.servlet.PageServlet
Producer jp.ne.dti.lares.foozy.pagemixer.mixer.Producer
Renderer jp.ne.dti.lares.foozy.pagemixer.mixer.Renderer
Token jp.ne.dti.lares.foozy.pagemixer.Token

Tutorial specific classes

No tutorial specific class is explained in this section.

Renderring procedure

PageMixer provides "PageServlet" derived from HttpServlet, and response renderring procedure of it is shown below. This allows you to focus only on implementation which is specific for your application.

  1. create ConsumerContext
  2. get servlet path from HttpServletRequest
  3. determine Locale of current request
  4. determine PageEntry by above path and locale
    1. determine 'page' information by path and locale
    2. get InputStream by 'resource location'
    3. create Producer from InputStream
  5. get encoding from PageEntry
  6. forward control to another page if required (, and return)
  7. create Filter to process token stream of page
  8. get Producer to produce token stream of page from PageEntry
  9. set content type of current response with the value from PageEntry
  10. get Writer from current response, of which encoding is from above content type
  11. create Renderer with above Wirter
  12. connect Filter to Renderer
  13. provide stream of Token to Filter by Producer, and this causes response renderring


As described before, PageServlet has some customization points, but is not designed as base class of "Template method" pattern. It is implemented by "Strategy" pattern, because it allows you to reuse(or combine) each strategies separately and reduces number of classes derived from PageServlet.

PageServlet decides what class should be used for each customization points in the steps shown below.

(1) use class specified in deployment descriptor:

When a construction parameter for a customization point is null, PageServlet uses the class of which class name is specified as Servlet init-param in deployment descriptor. Names of init-param for each customization points are explained in later sections.

(2) use one specified as construction parameter:

PageServlet uses one specified as construction parameter, only when it is not-null. In other words, the constructor of PageServlet has parameters corresponded to all customization points.

You can customize in this way by defining the class derived from PageServlet and using super() invocation with your specific strategy object(s) at its constructor.
This reduces the cost to desctibe deployment descriptor when almost all pages share same configuration.

(3) use base class:

When none specifies implementation class, PageServlet uses base class(= default implementation) for each customization points.

Please attention that any customization points do not have "default implementation" (= can not decide it).

Because above decision steps are applied for each customization points separately, you can configure one by (1), another by (2) and the other by (3) for example.

To next section "Create 'ConsumerContext'"