[stringtemplate-interest] The select-option problem

[Koerner, Ron]

Hi Zenaan,

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.

The view model and the view itself are highly coupled and if you change
the view you probably will have to change the code to generate the view
model.

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
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.

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

Regards,
Ron



-----Original Message-----
From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Zenaan
Harkness
Sent: Wednesday, July 22, 2009 7:02 PM
To: stringtemplate-interest at antlr.org
Subject: Re: [stringtemplate-interest] The select-option problem

> I have a fixed list of selectable options and a variable matching one
of
> the selected entries. I want to mark the selected entry in some way,
> e.g.:
> 
> <input type=radio name=opt value=opt1>
> ...
> <input type=radio name=opt value=opt2 checked=checked>
> ...
> <input type=radio name=opt value=opt3>

> I found some quite old mailing list entries that this is not easily
> possible

define 'easy'; if you mean, doing it all in ST, yes, not so easy;
otherwise, see below

> and since I can't use list comprehension here it is even more
> complicated.

more complete list fns should come in next+1 version of ST;
but likely low performance compared to View Controller, see below

> So I have two questions:
> 
> 1. Is there a possibility to do something like
> $if(eq(selected,"opt1"))$checked=checked$endif$ ? It doesn't look like
> that based on my inspection of the source code...

"business logic" is intended to be completely removed from view
generation; ST maximizes MVC separation above other considerations;

> 2. Shouldn't there be something like this?

allowing 'complex' expressions in your view templates is a slippery
slope, and leads almost immediately to views intertwined with business
logic. Just don't! is the answer. But the solution? View controller
class.

Expand your concept of Controller in MVC:

Model controllers ~= business logic;

View controllers ~= business presentation logic;

Your good taste as a systems designer will determine the effectiveness
with which you separate Model and View controllers, and how they
interact.

This is a form of MVC Recursion, or more generally,
Design Pattern Recursion.

You can think of your system as a whole having a model (entities and
their relationships), views (how to display the system), and controllers
(business logic).

Recursively, your model can have it's own MVC design, and your view can
have its own MVC design.

ST is doing us the great service of causing us to think of our systems
more methodically, to really get to the heart of a good design, by
consistently separating view generation infrastructure, from model
representation infrastructure, from model controller and as we can
clearly see here, even view controller infrastructure.

This strict requirement is actually ST's great contribution to the world
of template engines. Stick with it, and you will eventually reap the
benefits.

> As a reason why this is currently not there was stated a violation of
> model-view-separation. I think it is the contrary case. The current
> feature set requires the model to be adapted to satisfy the view!

That would indeed also be a violation of MVC! Don't do it, of course...

Expand your system concept, as described above. It is not that
"my code can only have model-specific stuff, because my code == my
model"

Indeed, you could code your views, and implement this in strict MVC.

ST merely goes a long way to making it easy for you to attain strict MVC
separation but cannot force you that way.

ST is strictly view production, not view controller/ view logic,
although it provides for some simple view logic.

So, you write your View Controller/ View Logic code, and keep it very
separate from your model controllers and model view (entity!) classes,
even though your view (ST) controller classes will need to rely on your
model's view (entity) classes.

It's a little complex because of the MVC Recursion...


> Proof:
> 
> The business logic requires a selection between several choices of
some
> kind. So this selected choice is in my model.
> The view is simply an text input box which is populated with the
current
> selection. Some Javascript code ensures no invalid values can be
> entered.
> Now someone says that looks ugly and wants a selection box or radio
> buttons.

> There is no possibility to implement that without changing the model,
> even if the displayed information is the same.

Your are restricting yourself with your self-imposed limitation 'there
is no possibility to implement such view controller logic...'.

What you meant of course was 'there's no easy way to implement my view
controller logic in ST'; and now that you say it in this way, you are
more correct, and more open to good solutions.

Solution is now obvious: implement view controller logic, in code,
outside of ST, separate to your model and separate to your model
controller; perhaps a layer between your model and your ST.

:)

Good luck,
Zenaan


-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.
_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest at antlr.org
http://www.antlr.org/mailman/listinfo/stringtemplate-interest

-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.