RSF Wiki: StaticComponentRenderer

More...

StaticComponentRenderer (SCR) is an interface which designates a template rewrite rule which proceeds directly on the template without the use of a component as peer.

The complete code for the interface appears here:

/** A component renderer that is dispatched by its name, with no peer component */
public interface StaticComponentRenderer {
 
  public String getName();
  public int render(XMLLump[] lumps, int lumpindex, XMLWriter xmlw);

To apply an SCR to process the markup for a tag, use an rsf:id for the tag in the template file beginning with the prefix scr=. The rest of the id following scr= is used as an index into a table of SCR instances that are indexed by name in the request scope.

`scr=rewrite-url`#

scr=rewrite-url is now no longer required to be applied in templates. It is inferred automatically for any tag which mentions a relative URL and which does not already have an rsf:id.

scr=rewrite-url looks up to the URLRewriteSCR, a standard RSF component which is used to rewrite URLs as they appear in their "natural" relative form, allowing relative URLs to resolve correctly when the template is viewed via the filesystem as it sits in the templates directory, into URLs that can be served to clients of the servlet. At the very least, some path components will need to be added into the URL, and for portlet/WSRP environments, the URL rewrites will be more serious. The scr=rewrite-url tag alerts RSF that somewhere amongst the attributes of this tag appears a URL that should be processed by the rewriter - the actual details of its operation are up to the RenderSystem involved.

The standard URLRewriteSCR for the HTML environment knows how to recognise the URL attributes of the <a>, <link> and <img> tags, and could easily be extended to deal with more without threatening the coherence of the system - URLRewriteSCR is designated as the (rather small) focus of such HTML-specific grunginess and is given significant latitute to do its job, containing code that, were it allowed to appear anywhere else in the system would be deemed "very bad".

`scr=portal-matter`#

Another use for an SCR rewriter is to blow request-specific references into markup, which are required by some hosting environment for your app (e.g. to request-synthesized Javascript calls required to be issued by tools hosted by the Sakai

framework). This is represented in RSF by the framework-neutral definition scr=portal-matter which can be placed on any material in the <head> section of HTML. At runtime, all of these will be removed and replaced by single copy of whatever head material is appropriate for the current portal.

`scr=head-collect` and the `scr=contribute` family#

Not only within portal environments, but when performing markup aggregation in general, definitions that would normally be placed in <head>, for example representing CSS stylesheets or JS definitions need to be treated separately. When creating a reusable "widget" or component, as well as aggregating its markup from the defining template, we need to make sure that one and only one copy of each of its CSS, JS files etc. are aggregated into the <head> of the final template.

For clients#

Clients in normal HTML environments need to do nothing - scr=head-collect, which marks the target tag where this material will be collected, is inferred automatically on <head>. In a "simple" portlet environment like Pluto, a simple and effective strategy can be to use a "fake" head definition on a <div>, in combination with a "layout" or outer page template, creating a layout beginning like this:

<!DOCTYPE html      PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<div class="portletBody" xmlns:rsf="http://ponder.org.uk/rsf">
  <!-- Intermediate approach to allow collection of head material into
    a fake "head" -->
  <div rsf:id="scr=head-collect">
  </div>

This is the approach used for example in the portlet version of the Hibernate Cookbook

For implementors#

For the implementor of a reusable widget, either scr=contribute-style or scr=contribute-script need to be placed on definitions in your <head>, as appropriate. Any other definitions will be considered for preview only, and will not be collected into the <head> of your clients. For example, all the Javascript files referred to in BuildingRSFComponents would be marked up with rsf:id="scr=contribute-script".

Benefits and purpose of SCRs#

Really, your imagination is the limit. The benefit to clients is, no matter what level of grunginess hides behind your SCRs interface, i) adding it into your app is just a matter of adding a reference to a Spring config file, and ii) adding a very simple attribute to the HTML target tag in the template file.

The non-static counterpart of SCR, which in addition takes the peering component as argument, is ComponentRenderer.