[stringtemplate-interest] The select-option problem

[Zenaan Harkness]

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