[stringtemplate-interest] format="random string" harmful

John Snyders jjsnyders at rcn.com
Sun Oct 1 18:57:21 PDT 2006


HiTerence,

I'm not 100% sure what way you are leaning on this. The subject and the
first part makes me think you are against the format option. Then you
propose to use function syntax (did you really mean functions or templates
with one arg that look like functions when called?) Functions seem to be for
operating on multi-value tempates or attributes and so far are not used for
rendering. In the end it seems you might be agreeing with the format option.

Perhaps I'm unclear on what you mean by users. Is the user the template
author?
I agree that the template authors should never be able to inject code into
the system and associate it with a template.

As for the hole in format you can do the same thing with a template because
a template can be associated with a renderer.

$bad(query="select * from Users")$

with a renderer attached to template bad the renderer's toString method is
called with the query string.

But this is not a problem because the template author is not able to add
renderers or associate renderers with templates.

> -----Original Message-----
> From: stringtemplate-interest-bounces at antlr.org
> [mailto:stringtemplate-interest-bounces at antlr.org]On Behalf Of Terence
> Parr
> Sent: Sunday, October 01, 2006 5:58 PM
> To: stringtemplate-interest
> Subject: [stringtemplate-interest] format="random string" harmful
>
>
> Hi,
>
> I just realized that allowing the random format string to dictate
> which function to call on some formatter object is way too big of a
> whole.  It is the same thing as velocity that allows you to pass in a
> model and call random methods on it.  Imagine:
>
> $"select * from Users"; format="query"$
>
> weird, but would call renderer.query("select * from Users").  Pass in
> a DB object and we have a problem.
>
>    I think that I need to stay probably with a predefined set of
> useful functions that you can apply to attributes.  In fact, the
> function style syntax of $upperCase(name)$ might be the right
> answer.  Regardless of the syntax, I think the only way to  enforce
> the separation is to prevent users from providing random code that
> you can call from the template.
>
>   I suppose with that limitation then
>
> $bday; format="verbose"$
>
> and
>
> $names; format="upperCase"$
>
>   can be the syntax.  It would be calling pre-existing functions with
> those names-- the user cannot provide those methods.
>
> Ter
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org:8080/mailman/listinfo/stringtemplate-interest


More information about the stringtemplate-interest mailing list