[stringtemplate-interest] format option implemented?

[Terence Parr]

On Dec 8, 2006, at 11:39 AM, John Snyders wrote:

> Has anyone implemented the format option yet?

Nope.

> I noticed that the bug database includes "singleton  
> renderers" (http://www.antlr.org:8888/browse/ST-5)
> Doesn't this need to be updated to include the format option syntax?

Yup...I just spent 30 minutes looking for and reading list entries  
related to this.

> I need this now so I'm going to start on it if no one has done it.

I can implement is very quickly, if we can finalize what really  
should happen.  Let me try to summarize what everyone was talking  
about because I'm pretty confused about what we agreed to do.  My  
brain is apparently shot. ;)

I think Oliver suggested that what we need now is already possible  
using template instance-specific renderers:

> 1. define a group with required templates
>   group foo;
>   shortDate() ::= "<it>"
>   longDate() ::= "<it>"
>
> 2. register custom attribute renderers for the _templates_:
>   group.lookupTemplate("shortDate").registerRenderer(Date.class,  
> new DateRenderer("MMM yy"));
>   group.lookupTemplate("longDate").registerRenderer(Date.class, new  
> DateRenderer("yyyy-MM-dd HH:mm:ss"));
>
> 3. apply templates:
>     $d:shortDate()$          to format an attribute d using short  
> format
>     $bar.date:longDate()$    to format bar's date property using  
> long format

Then we all thought that perhaps we should have $o; format="f"$  
invoke method f() on o's registered renderer.  But then in

http://www.antlr.org:8080/pipermail/stringtemplate-interest/2006- 
October/000691.html

I suggested that the following is too big of a hole:

$"select * from Users"; format="query"$

because it would call myStringRenderer.query("select * from Users")

Then I think we thought to extend the interface to include a format  
string:

public interface AttributeRenderer {
     public String toString(Object o);
     public String toString(Object o, String format);
}

$o.f$ would call oRenderer.toString(o, "f"), which still could be  
abused.  This is worse than calling oRenderer.toString(o) because you  
cannot pass information from the template to the renderer whereas you  
can with the format version.

So then we thought we should restrict formatters to a predefined set,  
with someone suggesting making predefined singleton formatters like  
js, html, url, etc... with things like

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/ 
MaskFormatter.html

we could get pretty far doing basic text formatting.

So, should we go towards some predefined formatters for various web  
related stuff such as js and html or should we go towards the  
existing strategy suggested by Oliver:

http://www.antlr.org:8080/pipermail/stringtemplate-interest/2006-July/ 
000512.html

That suggestion does not help us with some formatting needs though  
like specifying how much to pad an expression with whitespace or  
cropping etc.

In my bug report:

http://www.antlr.org:8888/browse/ST-5

I suggest:

> $name.toUpper$ would be converted to
>
> r = renderer.get("String");
> r.toUpper(name);

but that conflicts with the argument I started above that you could call

$"select * from Users"; format="query"$

and get to the arbitrary query method of the string renderer.  The  
more I think about it though I am not sure that this is a serious  
problem.  People would have to deliberately make the string renderer  
into a database object--a hole that already exists because you can  
register a string renderer that looked for strings that started with  
select and simply call the database:

$"select * from Users"$

So, shall I implement what I have in the bug list:

http://www.antlr.org:8888/browse/ST-5

The syntax as shown is $o.f$, but I think we'd decided later that it  
should be $o; format="f"$, right?

I think I have also decided that the format option would apply to the  
object value, not the entire expression, thus, avoiding issues with  
the separator.  It would apply to the null option, however, because  
that replaces an expression value.

   Sorry to rehash this, but for the life of me, I cannot remember  
what we decided.

Ter