This page is dumping ground for thoughts that will eventually end up in the Renderer user documentation.
The format of an
rsf:id gives the renderer guidance as to how to treat the element.
rsf:id s that begin with a shared prefix are repeading. If the suffix differs, then the type of element differs.
The component tree for a Select is not the same regardless of how it's being rendered. A
<select> element can do with a much simpler tree than a set of checkboxes or radio buttons. For the checkboxes/radio buttons, the tree needs to mention each one individually using the SelectChoice syntax, but for the
<select>, it seems to figure that out for itself. This could imply that SelectChoice "maps" to checkboxes or radio buttons, but not to
<option> in a
The Select syntax defines the data. Perhaps since
<option> only exists inside a
<select> and it's the only thing that can be inside a
<select>, then the template doesn't need to be that specific. But for radio buttons and checkboxes, the renderer doesn't and can't know which one is desired, and so the template needs to be specific. And the Select syntax lists all of the values, which can't be attached to a single checkbox, so...
Notes on general Renderer process
- moves linearly through the template file, simply copying from input to output, until a tag mentioning the rsf:id attribute is met
How to Create a Template
- A template is contained within a single container that can be identified to the renderer, e.g. through an ID or other form of selector.
- It's fine to have more than one template on a page.
- A single template will be process alongside a single component tree (the 'data').
- Things in the template should be thought of as samples of how the creator wants certain types of information to be rendered.
- Dan's words: "a series of examples, rather than a set of formal rules"
- Anything inside the template that does NOT have an
rsf:idtag will simply be rendered exactly as-is.
- Things with an
rsf:idtag will be used to render information in the component tree (but not necessarily in the order they're found in the template).
Notes on templates
- a template is "rather like a series of examples, rather than a set of formal rules"
- each bit of the template is sort of the a self-contained template for how to render something of that particular type
- the order that the template bits appear in the template is not necessarily the order in which the bits will be used to render the data
- the nesting of any template bits is important
- Each individual control individually fossilizes its own "old model state"