The maintenance nightmare happens when someone uses the embedded language to specify business logic, and that's entirely the web-{developer,designer}'s fault. Thus, the problem is not that these languages shouldn't be powerful enough.
<br><br>IMHO, a safe approach would be simply not allowing I/O inside templates (hey, sounds familiar ;-)<br><br><div><span class="gmail_quote">On 4/5/07, <b class="gmail_sendername">Maurice Codik</b> <<a href="mailto:maurice.codik@gmail.com">
maurice.codik@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>A few things, some of which I sort of mentioned in my previous email:
</div>
<div> </div>
<div>- If I'm already going to commit some time to learn a templating language, why dont I just spend that same amount of time learning the little bit of haskell I need to make the template work? If thats too much to ask, I can just spit out HTML, and have the programmer put in the dynamic parts for me. Both of these scenarios seem to be a more efficient use of time.
</div>
<div> </div>
<div>- Who is the target audience? If its a big organization where there are multiple designers and multiple devs, then your approach may work just fine. If its the single developer, then something like what David suggested would work even better. If its a small team (which may or may not include a full-time designer), then something like what I suggested would work best. For a web framework for haskell, I would guess that the latter two are much more likely.
</div>
<div> </div>
<div>- Embedding a real programming language in a template already gives you power to do what ever you need to do. What if you need to implement some logic that the template language doesnt support? In those cases, you're usually out of luck and have to move that logic into a controller, where it doesnt really belong (assuming its actual display logic, not business logic).
</div>
<div> </div>
<div>- It's really just a matter of taste. Any web framework thats worth using should be flexible in its support of view technologies, but come with one thats a sensible default. </div>
<div> </div>
<div>Maurice<br> </div><div><span class="e" id="q_111c2f7f1ec49af8_1">
<div><span class="gmail_quote">On 4/5/07, <b class="gmail_sendername">Joel Reymont</b> <<a href="mailto:joelr1@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">joelr1@gmail.com</a>> wrote:
</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Do you see anything wrong with the approach I suggested, though?<br><br>On Apr 5, 2007, at 6:16 PM, Maurice Codik wrote:
<br><br>> That's not necesarily true. Templates where there is mostly markup,<br>> but let you embed code into them using special tags (ex, <% code %<br>> >) are extremely popular and work fairly well. They also keep the
<br>> template language simple because there is already a full-powered<br>> programming language thats embedded into it. Good examples of this<br>> method are ERB templates in Rails, JSPs, Perl Mason templates, etc.
<br><br>--<br><a href="http://wagerlabs.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wagerlabs.com/</a><br><br><br><br><br><br></blockquote></div><br><br clear="all"><br></span></div>
<span class="sg">-- <br><a href="http://blog.mauricecodik.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://blog.mauricecodik.com</a>
</span><br>_______________________________________________<br>web-devel mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:web-devel@haskell.org">web-devel@haskell.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">
http://www.haskell.org/mailman/listinfo/web-devel</a><br><br></blockquote></div><br><br clear="all"><br>-- <br>Ricardo Guimarães Herrmann<br>"Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp"
<br>"Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"