[stringtemplate-interest] format option implemented?

[John Snyders]

Well I implemented ;format yesterday. I'll reply to specifics below.
I'll send details of the implementation in the next email.


> -----Original Message-----
> From: stringtemplate-interest-bounces at antlr.org
> [mailto:stringtemplate-interest-bounces at antlr.org]On Behalf Of Terence
> Parr
> Sent: Saturday, December 09, 2006 4:14 PM
> To: stringtemplate-interest
> Subject: Re: [stringtemplate-interest] format option implemented?
>
>
>
> 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'm not sure there was a clear agreement on the mailing list. Perhaps there
was before I joined.

> 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

Yes I did much the same thing at one point.
You said this approach would have a problem with the renderers getting
lost after the template was reloaded in the cache. This seems to be a
problem in itself.

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

In
http://www.antlr.org:8080/pipermail/stringtemplate-interest/2006-September/0
00681.html
I argued that ;format="f" was the most clear about the intent.

> 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);
> }

This is exactly what I did.

> $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.

I find the predefine set of formatters too limiting.

> 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"$

I agree that it is not that big a deal for the reasons I gave here
http://www.antlr.org:8080/pipermail/stringtemplate-interest/2006-October/000
696.html

It is the person writing the model/controller that would have to open things
up for abuse and they have many ways to choose from: map, template specific
renderer, and now format. No big deal as long as the template writer can't
add a JAR and get around the rules.

My current thinking is that the reflection needed to call a method "f" is
not worth it and that toString(o, "f") is just as safe.

> 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?

Again I like the format option and that is what I implemented.

> 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.

This gets a little tricky. Options are allowed on and apply to
templatesExpr.
Most of the time you will do $attribute;format="fancy"$ but it seems
incorrect
to me that $list : {a $it$ b};format={toUpper}$ would only apply to $it$ and
not
the whole annon template.
While perhaps not useful $\"literal\";format={toUpper}$ should also work (it
would result in "LITERAL")

The discussion on this list went on about the order but that turns out to be
a non issue since all options apply to the template. They are stored in a
hash map and hence have no order.

What naturally seemed to happen as I implemented this is that format applied
to the whole template and the null option value if used but not to the
separator.

I'll go into more details in the next email.

>    Sorry to rehash this, but for the life of me, I cannot remember
> what we decided.
>
> Ter
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org:8080/mailman/listinfo/stringtemplate-interest