Posts Tagged ‘SiteEntry’

Most of us might have seen the concept of Wrapper page in Fatwire projects. Even I too used to wonder what purpose this page might be serving, why is this used, etc.

I have seen this concept in many of the projects, and even in the FIRSTSITEII example site shipped with JSK. We will now see in brief, about wrapper page in Fatwire

A WRAPPER PAGE in FATWIRE is an ELEMENT (a CSElement, infact) that is called to perform the logic on the content server. Its sole purpose is to perform logic that must always be performed on Content Server even in a fully cached environment.

Following are few of the usages of a wrapper page:

  1. Checking security measures
  2. Setting default locale
  3. Getting the current locale
  4. Setting default values for parameters
  5. Validating URL
  6. Redirecting pages accordingly, etc.

The wrapper page (CSElement)  is usually not cached, while the Layout (template) usually is cached.

Creation of a wrapper page is a two step process.

  1. A CSElement should be created.
  2. A SiteEntry that points to the previously created CSElement. The SiteEntry must be declared as a “Wrapper Page”. Refer the below screenshot. The screen below shows the wrapper page option, in the SITEENTRY creation screen.


When you have a wrapper page created, you can even remove the external accessibility of the Layout.  In this case, the wrapper page will act as the ONLY entry point for a site.

So, when you create a WRAPPER PAGE in your implementation, what ever the page you view, the request will go to the WRAPPER PAGE first. Then the control will be passed to the respective pages (According to what we code in the wrapper). Hence, WE ARE NOT invoking the wrapper page manually. The wrapper page is getting invoked automatically by the content server.

In general, it is a good and common practice to implement a wrapper page and call it, rather than calling the layout page directly.

The cscacheinfo and sscacheinfo fields of the SiteCatalog are populated with a CacheInfo string. We are now going to discuss about the syntax of the CacheInfo String.

It is a two-part, comma separated string.

  • The first part tells whether the page should be cached or not.
  • The second part tells about the expiration.

Following is the screenshot which we can see while creating a Template / SiteEntry:


The first part in CacheInfo must be one of the following values:

  1. False  –   If the value is false, then the page will not be cached.
  2. True  –   If the value is true, then the page will be cached according to the information provided in the second element.
  3. (blank)  –  If the value is blank, then Content Server will consult the futuretense.ini property cs.alwaysusedisk. If this property is set to yes, then a blank value will be interpreted as having the same behavior as true. If the value is set to no , then a blank value will be interpreted as having the same behavior as false.
  4. *    –     If the value is *, then it will be treated as blank.

The Second part tells us when the cached page should be removed from cache. If the first element is false, then the second element is ignored. There are Five ways of specifying the expiration of a page.

  1. Page Timeout (in minutes)
  2. Absolute Moment in Time
  3. Time Pattern
  4. Wildcard
  5. Blank

Page Timeout:  If the second element starts with ~, then the value following the ~ must be an integer. This is the number of minutes a page will remain in cache. A negative value or “0” indicates that the page will never expire.

Absolute Moment in Time: If the second element starts with @, then the value following the @ must be a date expressed in the JDBC date string format, namely, YYYY-MM-DD HH:MM:SS. After the particular date and time, the cached pages will be flushed from cache.

Time Pattern: If the second element starts with #, then the value following the # must be a valid TimePattern string as defined by the public class COM.FutureTense.Util.TimePattern. It allows you to specify expiration at a specific time or times every day, month,week, day of week, and year.

Wildcard: If the second element is *, then the page will assume a timeout expiration behavior, as
described in Timeout above. The timeout value will be read from cs.pgCacheTimeout property of futuretense.ini file.

Blank: If the second element is blank, then it assumes the same behavior of *.

In this way, we can set the Caching for a page, and its expiration time.

Stay Tuned…!!!