[stringtemplate-interest] The select-option problem

[Zenaan Harkness]

> so I understand that stringtemplate should not access the business
> model, but needs a separate code layer which turns the business model
> into a specialized view model, which is then modified another time by
> the template engine (formatters, removing null elements) to be finally
> used to generate output.

Assuming the complexity of requirements that it seems you happen to need
for your system, then this might be a suitable approach to achieving
your requirements. It's a decision for you of course.

> The view model and the view itself are highly coupled and if you change

Good design principle is to minimize coupling. If you mean by "the view
itself", your ST templates, then there is still no reason to not
minimize coupling. At least to the extent you can.

But yes, the "view" model will have a greater 'coupling' with the view
templates (view view), than will the model model, model view, etc.

> the view you probably will have to change the code to generate the view
> model.

Your statement is not specific enough to be able to respond properly.

> On the other hand that means things like custom formatters and
> null-element-removal are actually violating this because they are
> putting logic into the template which actually belongs into the view

Yes, from the perspective of view view (templates) and view controller/
model, this is the case.

The question that has been and is still with the ST community, is what
can be included in ST 'code', whilst still strongly encouraging view and
model separation.

With MVC recursion, which should be self-evident by now, we also have to
be careful with our words, or we end up quite ambiguous.

> model generator. I'm sure there are more things. So why can't we have
> another thing which would be 100% pure functional and would not need us
> to revert to code which looks like a dirty hack.

No reason at all. I am personally an advocate for a goodly and full
functional grammar for ST.

Terence (sp?) who is the primary author of ST and ANTLR, is just
finishing a book, and then he is considering the creation of a formal ST
specification, as part of the ST 2.7? to 3.0 transition.

The first step will be specify existing behaviour, with some smallish
tidy ups here and there.

Second step will be specify enhancements.

Third step will be implement enhancements for ST 3.5 (or whatever it
gets called).

It will be a great benefit if you now make your enhancement proposal
in a clear and concise way, which is as suitable for a specification
document as you can achieve. You have joined the ST community at a
rather auspicious time...

Given that ST, being a templating language is sort of a reverse-grammar,
or anti-grammar, to specify it formally with a 'grammar' means an
anti-grammar grammar.

> I do not want a full fledged expression language, just an equality
> check...

Conditionals appears to be the concession to 'functional templating' at
the moment. They've been creeping in over time, getting more full
featured.

To create templates at the level that this community desires, they are
necessary.

Here's a thought: does it make sense to have two templating layers - the
low level 'pure ST declarative/ combinatorial templates' and a higher
view-controller/ view-model layer, which is a functional expression
language tailored specifically for views.

Intriguing...

We'd need to contemplate how the two layers would look, and how they
would interact.

I suspect that the view-controller and view-model will, due to their
potential complexity, simply be best implemented in a regular
programming language. I guess it would be good if someone were so
motivated as to create a lisp layer/ library, as ST controller layer.

Regards
Zenaan

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.