How pages are rendered

When a request is made to Weceem, it will go through a number of steps to product the final content.

Weceem will first locate the content at the URI path specified in the request. Once that is found, it will check if it is content that can be rendered - some content is not "standalone" and cannot be rendered directly, but is instead used by other content (e.g. Templates cannot be rendered directly).

Next, it will check to see if the content implements rendering itself. If so it will call the content's handleRequest method to perform the rendering of the response.

If there is no handleRequest method, Weceem will look for a "template" property on the content object and if it finds one, will ask that template to render the content.

Different content types may implement handleRequest differently. For example HTML Content will first check if the content is set to allow GSP tags to execute. If they are, it will execute the page and capture the output. The content is then passed to the template (if any) and returned to the client.

Note that if the content supports templates, if no template is set Weceem will look up the tree of content to see if any ancestors specify a template, and will use the first it finds.

In this most common case, the HTML and Template will work together and render one or more Widget nodes using <wcm:widget> to render common page elements like the header and footer sections.

Other types such as External Link will use handleRequest to issue a redirect to the browser.

Default document handling

Weceem supports httpd-style request URLs that end in / - it will automatically check for a child node of the URI, with one of the default names ("index.html" or "index"), much like a regular webserver.