title: Scala / Lift - Trying to understand Lift's simultaneous claim to use valid html and propensity for lift: tags and tag rewriting in render
body: <p>All of the Seven Things (<a href="http://seventhings.liftweb.net/" rel="noreferrer">http://seventhings.liftweb.net/</a>) are certainly nice, but I was particularly enthusiastic about the claim in Templates (<a href="http://seventhings.liftweb.net/templates" rel="noreferrer">http://seventhings.liftweb.net/templates</a>) that "Lift supports designer friendly templates." </p>
  
  <p>As one of my steps in learning Lift's way of doing things I'm attempting to create a simple object creation form: take a few parameters, use them as constructor arguments, then stow the object away. After some research and experimentation, tho, I have two concerns:</p>
  
  <ol>
  <li>There seems to be a considerable propensity for significantly rewriting/embellishing the template markup in snippets.</li>
  <li>Forms don't seem to use valid or recognizable html elements.</li>
  </ol>
  
  <p><strong>What I'm basing this on:</strong> </p>
  
  <p>The form examples/documentation seems all about special lift: tags. <em>Exploring Lift</em>  suggests that a form should look like this: (<a href="http://exploring.liftweb.net/master/index-6.html" rel="noreferrer">http://exploring.liftweb.net/master/index-6.html</a>) </p>
  
  <pre><code>&lt;lift:Ledger.add form="POST"&gt;
    &lt;entry:description /&gt;
    &lt;entry:amount /&gt;&lt;br /&gt;
    &lt;entry:submit /&gt;
  &lt;/lift:Ledger.add&gt;
  </code></pre>
  
  <p>I'm not sure that's even valid html5 and while it might be valid xhtml, it doesn't feel like that meets the spirit of having your templates look like real html for our designer friends. I read somewhere else (can't find it again) that we did have the option of using actual input tags, but then we wouldn't get some parts of Lift's fancy form wire-up or somesuch, the passage wasn't very clear on what exactly I'd be missing out and the examples don't seem interested in my writing a plain html form making a plain html post.</p>
  
  <p>The code for a demo.liftweb.net example (1) suggests that your template should look like this (2)</p>
  
  <pre><code>&lt;lift:surround with="default" at="content"&gt;
    &lt;div class="lift:PersonScreen"&gt;&lt;/div&gt;
  &lt;/lift:surround&gt;
  </code></pre>
  
  <p>The code for PersonScreen snippet isn't exactly illuminating, either (3). There are several other examples of a template that has, e.g. only a ul tag in a particular location only to generate a whole series of complex li's with nested elements in the snippet. Sure, you can use xml in Scala and it reads tolerably, but it's still scattering your markup everywhere. This seems to violate the spirit of "designer friendly templates".</p>
  
  <p><strong>What I want to understand.</strong></p>
  
  <p>For a long time I've strictly followed two rules in my webapp development:</p>
  
  <ol>
  <li>No markup in 'code' (controllers, business models).</li>
  <li>No business logic in the templates whatsoever.</li>
  </ol>
  
  <p>Idiomatic Lift seems to completely forego the first rule and completely miss the value of the second rule. These rules have served me well and I'm not ready to just follow along with the examples that seem to be violating them without understanding why its not going to create a mess. I want to understand why it's okay in Lift to have so much display code generated in the Snippets. I also want to understand why its okay that the markup in the templates so rarely reflects the output.</p>
  
  <p><strong>What I (think I) want:</strong></p>
  
  <p>I want all of my markup with very few, if any, exceptions to be in my templates. I want my snippets to do minimal template mangling, generally only replacing element text on "leaf" tags and possibly tweaking attribute values. I think I've done this for a reasonably complex display example and I suspect I could use the same technique to generate a vanilla html form and then handle the params myself. Is that what I need to do if I want my template to look like the end-result form?</p>
  
  <p>Responses and any other thoughts, especially on understand the Lift mindset regarding this stuff, would be tremendously appreciated.</p>
  
  <p>Thanks!</p>
  
  <ol>
  <li><a href="http://demo.liftweb.net/simple_screen?F674431078927QJVVYD=_" rel="noreferrer">http://demo.liftweb.net/simple_screen?F674431078927QJVVYD=_</a></li>
  <li><a href="https://github.com/lift/examples/blob/master/combo/example/src/main/webapp/simple_screen.html" rel="noreferrer">https://github.com/lift/examples/blob/master/combo/example/src/main/webapp/simple_screen.html</a></li>
  <li><a href="https://github.com/lift/examples/blob/master/combo/example/src/main/scala/net/liftweb/example/snippet/Wizard.scala#L94" rel="noreferrer">https://github.com/lift/examples/blob/master/combo/example/src/main/scala/net/liftweb/example/snippet/Wizard.scala#L94</a></li>
  </ol>
  
  <h2>EDIT</h2>
  
  <p>In response to @OXMO456. (Thanks for the response.)</p>
  
  <p>I have, and they seem to just confirm my concerns: E.g. we start with:</p>
  
  <blockquote>
    <p>Lift templates contain no executable code. They are pure, raw, valid HTML.</p>
  </blockquote>
  
  <p>which is awesome. Then later:</p>
  
  <blockquote>
    <p>The latter two mechanisms for invoking snippets will not result in valid Html5 templates.</p>
  </blockquote>
  
  <p>and yet everyone seems to use the first of those two mechanisms. Also, it says:</p>
  
  <blockquote>
    <p>Third, the designers don’t have to worry about learning to program anything in order to design HTML pages because the program execution is abstracted away from the HTML rather than embedded in the HTML.</p>
  </blockquote>
  
  <p>But pretty consistently the example snippets like the one I referenced in the OP generate markup entirely programmatically. This seems counter to the goals (a) of having designer friendly templates so the designers don't have to be bothered with Freemarker markup and (b) separating display logic from business logic.</p>
  
  <p>The second link is helpful and instructive, but it makes it pretty clear that this isn't The Lift Way. However, The Lift Way also seems to drag a whole load of markup generation into snippets, which is (I think) a huge compounding of markup and business logic. Is that The Lift Way?</p>