[stringtemplate-interest] Conditional statements

[David Moshal]

Kay - thanks for the references, I think I've read them before, but will
check.
I'm interested in Ter's take on all of this too.

Dave


On 5/6/06, Kay Roepke <kroepke at dolphin-services.de> wrote:
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org:8080/pipermail/stringtemplate-interest/attachments/20060507/f7454a99/attachment-0001.html