Web Development as Tag Soup

There is also Java annotation based HTML template system which uses 100% clean html templates. It ensures the same separation between code and template as the StringTemplate system by Terence Parr.
http://jabhts.org
The binding between the html and the java code is done using java annotations, so the coding overhead is minimal. It’s not fundamentalistic, so you can still output raw html if you want to.
It uses inner-classes in Java for providing extra scopes so your code doesn’t end up as one huge class, but enables dragging in sub-modules by creating derived inner-classes.

I second the nomination for TAL: it’s a very elegant templating language. But, as others have pointed out, the problem with your example isn’t the templating language (it almost never is) but rather a failure to enforce a separation of concerns by overloading the view.

I have used PHP (awful for this problem) and Common Lisp, using a couple of different libraries (see http://www.weitz.de/ and Parenscript). The Lisp method as mentioned previously is much cleaner than any other tool I’ve seen used.

Hi Jeff,

Apparently the ASP.net MVC is working on cleaning up the views, so you’re stuck with the poor templating code for now.

Have you seen what Genshi (http://genshi.edgewall.org/) are doing in comparison? They extend the HTML namespace with their custom attributes for for-loops, if-statements, etc. It’s python based though.

It reads like a charm and is easy to work with in an XML IDE.

Ciao,
Shaun

Apache Wicket (and from what I understand, Tapestry and JavaServer Faces) avoids this problem pretty well:

http://wicket.apache.org/

Most of the HTML is loadable without any server running, and special tags in the HTML represent server-side components that have their own markup that is also loadable without a server.

This is why I’m a fan of attribute based templating such as with TAL, where you can do things like:

h1 tal:content=view/titleTitle goes here/h1
ul
li tal:repeat=item view/items tal:content=item/nameitem name/li
/ul

You always end up with valid html and you’re somwhat enforced to have a strict model/view/controller separation - you simply can’t do anything fancy in the template and are forced to embed it in a view class (which is plain code)

I second (or third?) NHaml.

We’re using the NHaml view engine with the MVC framework on a very large website and it’s an absolute dream to work with compared to the default webforms view engine.

  • JD

JSF can really help minimize this in java. I’ve written JSF pages with little to no regular HTML at all in them using pure JSF tags instead and using CSS to take care of the look and feel. GWT also seems like a good solution, though I’ve not had much experience with it yet.

If you do have to embed code into a page, really try to move as much of it as possible out to utility methods that can be unit tested outside of the page.

I think the bigger a project gets, the more important it becomes to strictly separate code and presentation. Mixing code and markup is fine for smaller web applications, but it get messy soon.

Java’s JSF with Facelets (https://facelets.dev.java.net/nonav/docs/dev/docbook.html) is another MVC framework that uses plain XHTML for view construction. The only code is in the EL-expressions that bind page components to the model.

I’d second the call for Seaside. It’s a whole new way of working!

Tag soup is indeed a big problem and you can find examples of it in every language and framework but the Rails code you posted seems absolutely amateurish to me, and I’m an amateur! All of the loop logic can be removed by using a partial with a collection, Rails has a method (cycle) to accomplish the even/odd row magic, and those absurd link_to calls can be cleaned up by a few lines in the routes file. These aren’t advanced expert tricks either, these are the things pretty much any introductory Rails book teaches.

Personally I hate seeing variable declarations or any other script tags in my view code. I try to write my views with a complete non-programmer in mind; someone who doesn’t even understand simple decisions or loops. Your views become a lot easier to read and it forces you to truly separate view from controller.

What amazes me about Tag Soup as a problem is its longevity. Everyone knows it’s a problem. There were some kick ass holy wars over the past decade in the JSP community surrounding it. The decision trended towards, avoid as much as possible and move the logic into HTML-like tags.

Of course, this didn’t actually solve the problem, it just made it more readable…or so they said. It’s obvious this wasn’t the solution. If it was, PHP, Ruby, etc. wouldn’t be making the same mistakes trying to solve the same problem years later.

This makes me wonder how much of a problem it actually is. Certainly move your logic outside of the tags whenever possible. But:

c:if test=blah is really not much better than % if (blah) { %

The solution chosen will gravitate towards the familiarity of the programmer. An HTML designer may gravitate towards c:if while a Java programmer would pick the pure Java construct.

I should make clear i meant outputting the HTML with printf type functions (echo) and not using the functions like the property one recommended above. (Although this may be a good idea for some)

My HTML is still inside my PHP, its just well enough wrapped to not be confusing… at least for me. Comments help too. :slight_smile:

After looking at it a bit, ASP allows a similar method of writing a code module… it all comes down to personal preference at the end of the day, and there are a number of ways to make this problem manageable judging from the comments.

Jeff buddy - this post falls into the category of I don’t know WTF I’m doing so it must be THEIR FAULT. And while some of that is true - it’s also a bit on you friend. HELPERS are core to centralizing your View Logic. Rails, Django, blah blah framework - they all share this philosophy.

You can rewrite your mess quite easily and make it a ton more readable. This post is fail.

I’m not a Django expert, but I believe their philosophy is that template engine only fills the template with properties of objects provide as context. Last I looked, Django’s template engine didn’t, by design, even support obvious language features like assignment. However, it does provide simple ways to do presentation specific things like time and date formatting.

In my humble opinion, you can’t solve tag soup problem any better than that (perfectionist, pedantic and practical). In the real world web developers have to have direct access to the html/css so that they can apply hacks that allow 70% of browsers so render the pages correctly. That throws out all forms of light markup languages like markdown. Throwing more programming at the problem is unfeasible for the same reason and because then only programmers can make chances that should be doable for programming challenged web designers.

Jani, XSLT is also a mess. It’s a bit more readable because you use the same kind of markup to write html as well as to write xslt xml. The benefit here is that this setups really separates view from business logic. But it’s still hardly readable:

code
xsl:template match=article

	div class=article
		
		h2
			xsl:attribute name=classxsl:value-of select=category //xsl:attribute
			xsl:value-of select=title/
		/h2
		
		div class=body
			xsl:value-of select=body disable-output-escaping=yes /
		/div
		
		div class=info
			span class=commentSent: xsl:value-of select=created //span
			xsl:if test=string-length(updated)br /span class=commentUpdated: xsl:value-of select=updated //span/xsl:if
		/div
		
		div class=options
			axsl:attribute name=hrefxsl:textindex.php?m=articlesamp;a=viewamp;id=/xsl:textxsl:value-of select=@id//xsl:attributekomentarze/a,     
			axsl:attribute name=hrefxsl:textindex.php?m=articlesamp;a=editamp;id=/xsl:textxsl:value-of select=@id//xsl:attributeedytuj/a    
		/div
		
	/div
	
/xsl:template

/code

Dear. God. WTF?!

Tag soup is Eeeeeevil. This is the whole reason I switched to .NET, to get away from that crap. Now you’re telling me tag soup is back in action on ASP.NET MVC? I guess I’ll be skipping THAT beta test program.

Another vote for looking at HAML here. Just being able to lose closing tags is a boon for readability.

Another idea that Rails has (quite possibly borrowed/copied from somewhere else) is the helper function, where logic can be extracted to a proper code location.

With a few pretend helper functions thrown in (and there are other obvious ones left as an exercise for the student) I translate, the Typo Coding Horror above something like this:

  • c, f = 1, 1
  • for page in @pages
    %tr{:class=tr_class_for(page)}
    %td.first_col= page.created_at.strftime(’%d %b, %Y) #
    %td= title_link_for(page)
    %td= truncate(Post.strip_html(page.body), 50)
    %td= page.permalink
    %td.del_col= destroy_link_for(page)
    • c = (c == 1 ? c + 1 : c = 1)
    • f += 1
      -unless @pages.length 0
      %tr.header
      %th{:colspan = 5}
      .pagination
      .prev
      - if @page_pages.current.previous
      =link_to ‘laquo; Previous page’, { :sort = params[:sort], :page = @page_pages.current.previous }
      nbsp;
      .next
      nbsp;
      - if @page_pages.current.next
      =link__to ‘Next page raquo;’, { :sort = params[:sort], :page =? @page_pages.current.next }

(If the spacing doesn’t come out, then it’s better-indented here: http://pastie.org/237819 )

Now I’m no Rails or HAML expert. Honest. But that looks a hell of a lot better to me, and I’d bet the effect would be similar in an ASP.NET environment. I’d like to see it, anyway.

XML + XSLT certainly helps, but if done naively you still wind up with XSLT code sprinkled throughout your HTML which can be hard to read. We eventually built lots of XSLT templates for the most common HTML that we produce, which at least localises the problem. See https://dev.youdevise.com/YDBlog/index.php?title=hiding_xslt_tag_soup for more details.

I’m surprised that no one seems to have mentioned Hpricot (which is included in the Camping microframework, both by the inimitable genius that is why the lucky stiff). It leverages Ruby to produce a really nice little domain-specific language specific to producing HTML. The code at http://pastie.org/238265 produces the following HTML: http://pastie.org/238267