[stringtemplate-interest] Renderer "modes"

Kunle Odutola Kunle_Odutola at hotmail.com
Mon Jun 19 10:18:01 PDT 2006


Hi Sean,

> Without knowing of an easy way to fix this (by easy I mean not having two
> arrays of preformatted information being sent to the view, which seems
kinda
> wrong), I was thinking about having rendering modes for an
> AttributeRenderer.

Formatter ojects are currently the prescribed way. See the types in the
"Antlr.StringTemplate.Utils" namespace. You wrap each entry in your array.

> So I would be able to do something like this (ignoring the syntax I've
> used):
>
> <a onclick="DoSomething('$it.Name.FullName;
> format="js"$'>$it.Name.LastName$, $it.Name.FirstName$</a>
>
> with the attribute renderer for a string being (C#):
>
> class StringRenderer : IAttributeRenderer
> {
>     public string ToString(object data) { return
> HtmlTools.EncodeHtml((string)data);
> }
>
>     [Format("js")]
>     public string AsJs (object data) { return
HtmlTools.EncodeJs((string)data);
> }
> }
>
> Is there something like this already available in ST?

No. Am I right ti suspect you already have a patch?  ;-)

> If not, is it possible? It doesn't seem (to me) to breach the MVCR
> principals, as we're not executing arbitary code, rather making the
> renderers a little more flexable.

Perhaps. I wonder if formalizing the concept of Formatters would be a better
approach. Formatters expose arbitrary properties that ST templates can
already access directly. All that is needed is a way to compose a renderer
and a formatter before registering with ST. This would remove the
formatter-per-attribute association as well.

Simply combining the concepts (i.e. renderers exposing formatter-like
properties in addition to ToString) seems a little brittle. Can't articulate
why it feels brittle yet.


Kunle


More information about the stringtemplate-interest mailing list