[stringtemplate-interest] Conditional statements

Kay Roepke kroepke at dolphin-services.de
Sat May 6 13:46:49 PDT 2006


On 6. May 2006, at 22:15 Uhr, David Moshal wrote:

> Take the issue of Formatting of dates and numbers. This is a case of
> applying
> an expression to the model, to create a particular view of the data.

Yes. I agree with that.

> With ST currently if one wants to create, a table by iterating  
> through a
> collection of objects,
> in which the cells need to be formatted in a particular way, those  
> objects
> need to provide the formatted
> 'view' of the model, so either one creates custom objects in the  
> controller,
> applying the formatting rules
> to the model, or one alters the model object, so that it knows how  
> to format
> it's data for the view.

When you want to separate the view and the model from each other,  
this is exactly the thing
you'd want the controller to do. (To that part I was agreeing above.)
In my experience you could do one of two things:
1) Push the pre-formatted objects/data into the view/template or
2) Pull the formatting from the model via the controller by way of  
directions you put
	in the template (in effect like method calls)

I have done both things in projects. Both have their advantages as  
well as disadvantages.
I don't know whether you are aware if this paper[1] which Ter wrote.  
He talks a bit about the
problems (2) poses to the MVC paradigm (section 7.1). Although you  
could still decouple your model from the
view in such a scenario in invariably means that you complicate you  
controller. You will have
a formatting layer into which you call from the template that  
automagically handles the data
formatting for you. You could even do that lazily and wouldn't even  
take a big performance hit.
Ter als wrote a paper[2] recently in which he talks about the  
challenges of i18n in templates.
That might help you to decide how to proceed, too.

> So, in the case of formatting, wouldn't it be helpful if the  
> template had
> some
> evaluative capabilities that go beyond boolean evaluation??

Although I'm often tempted to do something like that, too, I would  
disagree in this case.
Having a formatting layer really only makes sense, if it tightly  
integrated into the template
system. Which in turn would put the user of ST in a position of  
either using that, or push all
data into the template anyway (a proof is in [1] section 7.1, too).
When and if you have such a formatting layer, your life is good. If  
you don't, it ain't.
I'm currently using approach (1) at work and other projects (ANTLR  
for one thing), too and
can live with it. But (2) really puts a lot of the controller into  
the template, which may or
may not be a Good Thing. That really depends on the assumptions you  
can make about the environment
you work in.
For ST, I think we shouldn't make to strong assumptions. Boolean  
expression, yes. More than that, no.
IMHO.

Ter?

-k

[1] http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
[2] http://www.cs.usfca.edu/~parrt/papers/i18n.pdf


More information about the stringtemplate-interest mailing list