[stringtemplate-interest] Conditional statements
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
> 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
> need to provide the formatted
> 'view' of the model, so either one creates custom objects in the
> 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 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 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
> 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  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.
More information about the stringtemplate-interest