The view template is one of the inputs to the IKAT renderer, which is used as its "model" for the output file it is to produce. The view template is the main source of actual tags in the target XML dialect, the only other source being the small ComponentRenderer and StaticComponentRenderer objects stored within the RenderSystem for that dialect. No mention, for example, of HTML tags should appear anywhere else in an RSF application.

The only addition made to the view template in terms of the target XML dialect is the rsf:id attribute, which is applied to tags which will be expected to peer with a UIComponent supplied by the ComponentProducer. These components form part of the view tree, the second major input to the IKAT renderer. The process of rendering involves "weaving together" these two inputs, alternating between template-driven iteration and component-driven iteration during the generation of the rendered output.

A section of a sample XHTML view template is shown here:

  <table rsf:id="message-row:" cellspacing="0" cellpadding="0">
    <tr>
      <td class="vertical-thing-class" rsf:id="tmiblock:2"> <img
                  src="../images/threaded-indent-2.png" alt=""
                  rsf:id="scr=rewrite-url"/>
      </td>
      <td width="70%" class="message-body"> 
         <div rsf:id="message-pane:">To be
           clear, Mozilla will not display the ]&gt; if the document is served as
          ...

This shows a variety of HTML and RSF constructs. The most important distinction is between rsf:id values which contain colons, and those which do not. As explained in the section on IDs, an ID value containing a colon will peer with a UIContainer[1] component representing a "branch point" of the IKAT rendering algorithm, whereas an ID with no colon will peer with a non-container UIComponent instance, representing a leaf of the component tree.

The only other class of rsf:id are those containing an equals sign =, such as "scr=rewrite-url" above. Currently the only text allowed to appear before = is scr, standing for StaticComponentRenderer, an interface expressing a template rewrite rule that acts on a template tag without any component peer.


[#1] For those of you familiar with the JSF component hierarchy, the UIContainer class will be a slight "false friend", since although it appears to have a "containment" function, its only semantic purpose is to guide the rendering process past a branch. In RSF, any rendering-level groupings are solely governed by the tag nesting structure of the template itself, and not by the component tree definition.

You can post comments and questions on this page using the following blog. Please set your name using UserPreferences before posting.
New entry

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-) was last changed on 19-Jul-2006 09:36 by UnknownAuthor