The example you have feels a bit like a straw man put forward for your readers to tear apart - its full of logic that could have been elsewhere.
Templates (we are a PHP shop and use Savant) can reduce the issue of tag soup to insignificance if you can avoid the temptation of making them monolithic and full of logic. I think by and large thats been the response by posters above.
A declarative approach can also work - using XSLT is a declarative approach (with the option of some xpath logic).
@Rob Conery
Unbelievable Rob are you still advocating that sloppy style of coding where you embed tons of code in your presentation view? Rob you’re doing it wrong! 
Getting rid of code-soup is one of the reason I like ASP.net so much… my code doesn’t look anything like that monstrosity.
Vincent,
MVC has been around a lot longer than Rails.
And, within the constraints of MVC, there isn’t a lot of room for interpretation.
Obviously, Data Model, View and Controller objects need to be created. And it needs an adapter/router/dispatcher (whatever you want to call it) to connect the web paradigm of URLs to a corresponding controller object.
So yes, it is similar to Rails. But no, it’s not a copy per se.
1 point by mattmcknight 1 minute ago | link | edit | delete
I like using the builder approach in Ruby.
x.html {
x.head
x.body {
for i in 1..5 {
x.div(:id = i) {
yo
…
but my designer likes the templating stuff better. With a good IDE, it does become pretty easy to tell the code from the template.
Another advantage of having clean HTML code is that it is much easier to go from design mockups to actual templates and back again.
Many people are on the defense here, saying that the example is over the top, and that it would be easy to do much cleaner with a little more discipline/ another ‘mvc’ framework. That’s true in theory, but in my experience in practice if people can take short cuts, they will (at least someone in the team will), so if technology doesn’t enforce separating logic from presentation code, many projects will end up with tag soup.
Another advantage of having clean HTML code is that it is much easier to go from design mockups to actual templates and back again.
Many people are on the defense here, saying that the example is over the top, and that it would be easy to do much cleaner with a little more discipline/ another ‘mvc’ framework. That’s true in theory, but in my experience in practice if people can take short cuts, they will (at least someone in the team will), so if technology doesn’t enforce separating logic from presentation code, many projects will end up with tag soup.
Why just not use a framework like the Google web toolkit to avoid all this. Use Java to program a website, and use all the benefits Java has to offer. Let the compiler translate all that good to read and maintainable Java code to web code. Then just use Tomcat to host your site.
This avoids using place your technology here with html all together. Off course there are other methods and frameworks if you don’t like Google 
@Shane : for sure, I remember reading about MVC in a visual C++/MFC book back in '98 ! And that wasn’t new already … anyway, porting that paradigm to web applications can take several forms, design decisions, … and I wouldn’t say it’s all about coincidences here
But if I mentioned it, it’s more about setting the record straight, when I read microsoft kiddies saying, ‘hooray, asp.net’MVC does it better than anyone else with its brand new concepts’. And guess what, the first thing they’ll do is producing the very same code Jeff is mentioning in his article, that is, poorly written view code not using all the helpers available in their framework. And people will rant on MVC’s tag soup while the problem is between the keyboard and the chair, starting the same cycle again …
I agree. This is a poor strawman. This was 3 minutes of work, having to deal w/ the ___'s, and there’s more we could do. I agree. HTML is crap, and it’s all messed up, but it can be minimized.
% pages.each { |page|
____class = cycle(first_row,alt_row,)
____page_created_time = page.created_at.strftime(’%d %b, %Y)
_link_title = (page.title == ‘’ ? ‘[Untitled]’ : page.title)
link_url = Site.full_url + ‘/admin/pages/edit/’ + page.id.to_s
____truncated_body = truncate(Post.strip_html(page.body), 50)
____delete_url = Site.full_url + ‘/admin/pages/destroy/’ + page.id.to_s
%
___tr class=%= class %
________td class=first_col%= page_created_time %/td
________td%= link_to link_title, link_url %/td
________td%= truncated_body %/td
________td%= page.permalink %/td
________td class=del_col
____________%= link_to ‘X’, delete_url,
____________:confirm = You are about to delete this page. This is perrnanent.\n\nAre you ABSOLUTELY sure? %
________/td
____/tr
% } -%
% if pages.length == 0 # This was a needless unless?!?! -%
____tr class=first row
________td class=first_col colspan=S
____________span class=gray
________________There are no pages at this time.
____________/span
________/td
____/tr
% end -%
% if page_pages %
____tr class=header
________th colspan=S
____________div class='pagination
________________div class=prev
____________________%= link_to ‘laquo; Previous page’,
________________________________{ :sort = params[:sort],
__________________________________:page = page_pages.current.previous }
________________________if page_pages.current.previous %
________________/div
________________div class=next
____________________%= link_to ‘Next page raquo;’,
________________________________{ :sort = params[:sort],
__________________________________:page = page_pages.current.next }
________________________if page_pages.current.next %
________________/div
____________/div
________/th
____/tr
% end %
Drupal avoids this very, very well.
Zope’s TAL is the better way - it doesn’t invent it’s own tags, and doesn’t add foreign markup. All template control is done in attributes, so HTML stays lean, readable, syntax highlighting works as usual.
TAL howto:
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.stx
PHP implementation:
http://phptal.sf.net
It could be that the real tax of the tag soup is the angle-bracket-tax. The inherant grossness of html makes hybridizing these things difficult.
Long story short I can’t see us coming up with a better way of doing the same kinds of things. It helps to have a little of the functionality in with the markup. Keeps the designers aware of what’s going on.
Even though you’re playing Operation, at least you’re not playing blind like you have to with regular asp.net.
It is amazing how things stay the same, but with fancier tags.
For large applications, having most markup and javascript emitted from the server is safer. Perhaps the client side markup should just be targets for the emitted code.
I’m just glad you said all that because I, not being the most experienced, have always thought, huh? when it comes to MVC and templating. It always looked like so much mixed up. just because it wasn’t server side code didn’t make it more readable. You said a necessary evil, and that made me understand I wasn’t alone in my thoughts. Thanks.
Part of the problem you are having above is that the inline html/javascript is just strings as far as the compiler is concerned. Thus the compiler can’t help you confirm that the syntax of the emitted html javascript is correct.
If you follow either the lispers or the smalltalkers (http://www.seaside.st/) you will see they both go in the direction of expressing their html in code, and thus the development environment can help the programmer keep it all straight.
In simple terms, what you have above is two language domains when you should have one.
The only solution i see to this problem that is a little different is intermediate representation. Like generating an XML from the server side code and transforming it via a XSLT (But i think that it could apply to any intermediate representation of the data the view need and transformation language).
But i don’t really know if it is better, only different.
If you have low-level code mixed in with html markup you’ve already failed, you might as well dump your current technology stack and start over with perl print statements that include html. If your abstraction is that leaky it’s probably not worth using at all.
@Tim,
I simply used UltraEdit to convert my tabs into 4 underscores
I think the use of left and right angle brackets do no ease the reading of RHTML, its syntax is also way to permissive.