exploring inline decision-logic in templates

ex1.php

<!-- here's the PHP'ish way of making inline decisions while constructing HTML markup -->

<select name="foobar">
   <option value="bam" <?=($foobar==="bam"?"selected":"")?>>Bam</option>
   <option value="baz" <?=($foobar==="baz"?"selected":"")?>>Baz</option>
</select>

<input type="radio" name="foobar" value="bam" <?=($foobar==="bam"?"checked":"")?>> Bam
<input type="radio" name="foobar" value="baz" <?=($foobar==="baz"?"checked":"")?>> Baz

ex2.php

<!-- here's another PHP'ish approach using parameterized function calling -->

<?php
function selected($val,$test){ return ($val===$test?"selected":""); }
function checked($val,$test){ return ($val===$test?"checked":""); }
?>

<select name="foobar">
   <option value="bam" <?=selected($foobar,"bam")?>>Bam</option>
   <option value="baz" <?=selected($foobar,"baz")?>>Baz</option>
</select>

<input type="radio" name="foobar" value="bam" <?=checked($foobar,"bam")?>> Bam
<input type="radio" name="foobar" value="baz" <?=checked($foobar,"baz")?>> Baz

ex3.php

<!-- this illustrates the same problem but not in relation to forms. specifically,
the problem revolves around how to cleanly make conditional inclusion of small 
snippets of markup inside other bigger markup templates. -->


<a href="<?=$bam?>" <?=isExternalLink($bam)?"target=_blank":""?>>Bam</a>
<a href="<?=$baz?>" <?=isExternalLink($baz)?"target=_blank":""?>>Baz</a>

ex4.handlegrips.tmpl.html

<!--
one approach I'm considering for handlegrips:
   http://github.com/getify/handlegrips

let you pre-compute a comparison hash for a data value (`data.foobar`) against a set
of values (`"bar","baz"`), and only make the assignment for the matching set value in
the comparison hash.
-->


{$: "#foobar" | data.foobar{"bar","baz"} = "checked" }

   <input name="foobar" value="bar" {$=data.foobar{"bar"}$}>
   <input name="foobar" value="baz" {$=data.foobar{"baz"}$}>

{$}

ex5.handlegrips.tmpl.html

<!--
an alternative approach I'm considering for handlegrips:
   http://github.com/getify/handlegrips

kind of like an array comprehension, where you can specify a set-literal as the
looping context of values, so your computation happens once for each iteration.
-->


{$: "#foobar" }

   <!-- {$* is the looping construct. this example allows a set literal for the
        looping context. you then evaluate the loop expression for each iteration,
        setting a helper local variable `checked` to use in the markup.
   -->

   {$* ["bar","baz"] | checked = (data.foobar==.) ? "checked" }
      <input name="foobar" value="{$=.$}" {$=checked$}>
   {$}

{$}

Don't you just have a function that sets the selected on the DOM given a model? you'd just bind a change in the model to that function so when a change happens it'll set the selected. Wll all you have to do is setup your template without any selected and fire off that function manually on the DOM structure before displaying it on the page.

If you've got a conditional that depends on data then you can make that data a model and update the DOM accordingly with a handler. No template logic is ever needed - it's just a quicker way to define what could go in code. If anything I'd argue that it's worse to put it in the template because you'll be tempted to just re-render the entire template rather than a small change, though it will make things faster on initial render

@rhysbrettbowen-

I think what you're pointing out is valid but orthagonal to the question at hand. The context of this question is how to handle a specific task in the template-string rendering approach.

Sure, dynamic live updating of simple properties probably should NOT occur with a whole re-rendering of a template partial for the surrounding element... that would be overkill.

But templating stands on its own as a valid approach for initial view rendering (especially on the server). I know some people would prefer that all UI is built via DOM manipulation, but that's also very distasteful to many others for lots of reasons. Look at the most recent updates from Twitter, where they've gone back to a server-rendered view (using template-strings, undoubtedly) approach, because they found that to be more performant for what they care about.

Essentially, there are two different paradigms: string-based template rendering, and DOM-manipulation based rendering. They are both equally valid, and depending on needs you would do either or both in a project.

But I don't think it's valid to blanket claim (without any supporting detail) "It should just be done in a totally different paradigm."