[stringtemplate-interest] Renderer "modes"

[Sean St. Quentin]

>
> Not quite. I thought we could just alter the following method:
>     rawGetObjectProperty(StringTemplate self, Object o, String
> propertyName)
>
> It would need to understand that an AttributeRender may also have a
> formatter that exposes additional properties.
>
> interface AttributeRenderer {
>     AttributeFormatter getFormatter();
>     string toString(Object data);
> }
>
> interface AttributeFormatter {
>     string toString(Object data, String propertyName);
> }
>
> class StringRenderer implements AttributeRenderer {
>     public StringRenderer() {}
>     public StringRenderer(AttributeFormatter formatter) {...}
>     AttributeFormatter getFormatter() { return formatter; }
>     toString(Object data) {...}
> }
>
> class JsAndHtmlStringRenderer implements AttributeFormatter {
>
>     toString(Object data, String propertyName) {
>         if ( propertyName.equals("js") )
>             return this.JsEncode(data);
>         else if ( propertyName.equals("url") )
>             return this.UrlEncode(data);
>         ...
>     }
> }
>
> 1. The rawGetObjectProperty() method can check if renderer has a formatter
> (via AttributeRenderer's getFormatter() accessor) and if so, use it
> directly.
> 2.  Not sure that the formatter needs to implement a specific interface or
> indeed be a separate object from the renderer.
> 3. Perhaps we can mandate that the "format string" is actually an exposed
> property on the formatter, ST already has the machinery to query
> properties/methods on arbitary object instances.


Ahh, I see what you mean... how about:

class StringRenderer : AttributeRenderer
{
    string toString(Object data) { return (string)data; }
    string asJs(Object data) { return JsFormatter.format((string)data); }

    // etc...
}

So we're not imposing interfaces on the formatters...

Agreed with #3, as I can see this:

$sqldb.select_star_from_users$ or $sqldb;format="select_star_from_users"$

All you need to do on the renderer or formatter is propertyName.Replace("_",
" ").Replace("star", "*") and you have a valid SQL string.

Haven't thought about any other options yet. Sean's idea is neat but it's
> use of attributes will require Java 1.5+. It doesn't quite equate to
> allowing passing arbitary strings to be passed from templates to
> controller
> though.


How about some sort of convention instead, so for example if your format
string is "js" then you'd need a method "string AsJs(object)" on the
renderer or formatter.  Much like how ST searches for "get" prefixes on
attributes -> $obj.value$ calls "string getValue()".

Then you could modify the convention by using attributes, so you could have
"[Format("js"), Format("js2")] string FormatToJs(object)". Its a similar
approach to how NUnit operates, by using [Test] or prefixing a method name
with Test.


Cheers,
Sean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org:8080/pipermail/stringtemplate-interest/attachments/20060621/7ffa5df4/attachment.html