[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