[stringtemplate-interest] General thoughts on enforcing separation

[John Snyders]

I suppose this issue has been discussed many times before but I was thinking
about it because of the current discussion about the ;format option proposal
so I thought I would add my input.

The paper “Enforcing Strict Model-View Separation in Template Engines” is
very convincing (at least to me) in its argument that the template engine
should enforce the rules of separation. It states that the rules of
separation 1 through 4 can be enforced.

The trouble is that the template engine must be realized in some
general-purpose language and integrated in such a way that the controller
can call the template engine to produce output. In doing this there will be
practical considerations that could provide an opportunity for abuse. The
ones I know of in the Java implementation of StringTemplate are:
 - Properties – these are getter methods that are called and they could have
side effects
 - Attributes that implement map – The Map get method is called with an
arbitrary string. The method could do arbitrary computation with the string.
 - Custom renderer per template – The renderer toString method can be passed
an arbitrary string and can do anything it wants with it.

Did I miss any?
Are these serious problems? I don’t think so.

The way I think about enforcement is to imagine there are two roles, that of
the template author and the controller/model developer. I imagine that the
template author is very smart and crafty and really wants to put business
logic of any kind into the template. The model developer is a staunch
supporter of the principals of view-model separation. That is why he or she
chose StringTemplate. The developer has the source code locked down so that
the template author cannot add or modify any code. The developer knows
better than to create properties with side effects or maps or renderers that
allow the template to do arbitrary calculations.

>From this point of view I think StringTemplate has done everything it can to
enforce separation. The developer is an ally. The fact that the developer
can subvert StringTemplate is not a concern. The developer can conceivably
choose not to use StringTemplate in the first place. If StringTemplate tried
to guard against the developer it would become too restrictive. It is the
template author that must be kept from breaking the rules either on purpose
or by accident.

StringTemplate documentation must state how to implement properties, maps
and renderers properly.

Now it may be the case sometimes (many times?) that the template author and
developer are the same person. Still the developer should not let the
template author touch the code :-)

-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org:8080/pipermail/stringtemplate-interest/attachments/20061001/f2a59a8e/attachment-0001.html