I don't always agree with Jeff Atwood, but he does make me think. Over at Coding Horror, he uses a reader comment as a starting point for a discussion on the question of whether code should generate HTML.
One of the mantras of professional web development is:
In layman's terms that means information about what to display and how you display it are kept in separate bins.
Why all the fuss? By doing this, you gain a lot of flexibility in operation of your website. Consider our blogging software. We host the blogs of hundreds of customers. Each customer has several bloggers, with (hopefully) boatloads of posts. Each customer has distinctive branding which needs to be emulated by the blog.
Posts are content. The layout, graphics, and widgets of the blog are related to presentation. If we didn't separate these things, chances are customers would lose the ability to specify what they want on the page.
As Atwood notes in his post, this separation is typically achieved through a template language. Templates frequently look like HTML plus some additional stuff that specifies that something goes here and there. If you've ever used mail merge in a word processor document, you've seen this paradigm in action before.
That other stuff usually looks like special tags or programming notation. For our application pages, the pages that are seen by content authors and blog administrators, we use the Smarty template engine. It's based on PHP, and our web application framework has good integration with it.
Atwood argues that for simple page compositions, templating engines are good enough, but things get hairy when you have to do things like repeatedly perform an operation over a list of things. To demonstrate his point, he uses a snippet of ASP.NET code that uses both looping and conditionals. It's not pretty.
In Atwood's opinion, the problem is resolved by writing generator functions which return blocks of expanded HTML. He cites Visual Basic XML Literals and X# as ways to achieve this.
I don't know if I find Atwood's argument to be persuasive. I think his problem is that he isn't working with a sufficiently powerful templating language. In this context, "powerful" means that you have the tools to do nontrivial things with concise, yet readable syntax.
Smarty, for example, supports looping and conditionals, so you don't have to fall back on the clutter of a full blown programming language. You can also write plug-in modules that will perform specialized generation operations.
An even more powerful concept, which is supported in our web application framework, is the notion of slots and layers. This allows you to break a complicated page layout into subtemplates that are then combined at render time. They may also require the calling of additional page rendering operations behind the scenes.
When JavaScript is allowed to be part of the solution, you can introduce a whole other world of opportunities. Tabular and conditional situations can be handled via user interface libraries and AJAX calls to web service endpoints.
We make extensive use of such techniques on our content creation and administration pages. For example, let's say an administrator wants to see a listing of users who are associated with a customer account. The request is handled through a web service endpoint and then displayed using a data table widget supplied by the Yahoo user interface library. Logic can be either offloaded to the web service by specifying parameters to the API call, or it can be dealt with by the administrator's web browser via JavaScript code.
The display of blog pages is handled by a different apparatus altogether. We have a web service that is dedicated to the rendering of blog page HTML. It knows about the types of content that can appear on a page, but it knows nothing about the customer's posts. That's stored on a completely different server. It also knows nothing about what a user has specified for display on a page because that is hosted on a different server.
When it's time to display a blog page, the service gets a bundle of data about what will be dropped into the page. It then fetches a template that describes the layout of the page and transforms the content into real HTML. To provide security on our end and simplicity for the page designer, we developed a template language that has limited looping and conditional constructs. It also has a tag set that is descriptive of the types of things that appear on a page.
We've been using this system since late April, and it has proved to be very flexible. We were able to not only migrate existing customers onto the system, we also introduced a second generation base template with a much better structure and styling design. Our product support team has been able to use the technology to ensure that our customers' blogs resemble closely the branding used on their primary websites.
Compendium is more than just affordable blogging software. We are providing a reliable service built on state-of-the-art web technology and best practices.
One of the mantras of professional web development is:
Separate content from presentation.
In layman's terms that means information about what to display and how you display it are kept in separate bins.
Why all the fuss? By doing this, you gain a lot of flexibility in operation of your website. Consider our blogging software. We host the blogs of hundreds of customers. Each customer has several bloggers, with (hopefully) boatloads of posts. Each customer has distinctive branding which needs to be emulated by the blog.
Posts are content. The layout, graphics, and widgets of the blog are related to presentation. If we didn't separate these things, chances are customers would lose the ability to specify what they want on the page.
As Atwood notes in his post, this separation is typically achieved through a template language. Templates frequently look like HTML plus some additional stuff that specifies that something goes here and there. If you've ever used mail merge in a word processor document, you've seen this paradigm in action before.
That other stuff usually looks like special tags or programming notation. For our application pages, the pages that are seen by content authors and blog administrators, we use the Smarty template engine. It's based on PHP, and our web application framework has good integration with it.
Atwood argues that for simple page compositions, templating engines are good enough, but things get hairy when you have to do things like repeatedly perform an operation over a list of things. To demonstrate his point, he uses a snippet of ASP.NET code that uses both looping and conditionals. It's not pretty.
In Atwood's opinion, the problem is resolved by writing generator functions which return blocks of expanded HTML. He cites Visual Basic XML Literals and X# as ways to achieve this.
I don't know if I find Atwood's argument to be persuasive. I think his problem is that he isn't working with a sufficiently powerful templating language. In this context, "powerful" means that you have the tools to do nontrivial things with concise, yet readable syntax.
Smarty, for example, supports looping and conditionals, so you don't have to fall back on the clutter of a full blown programming language. You can also write plug-in modules that will perform specialized generation operations.
An even more powerful concept, which is supported in our web application framework, is the notion of slots and layers. This allows you to break a complicated page layout into subtemplates that are then combined at render time. They may also require the calling of additional page rendering operations behind the scenes.
When JavaScript is allowed to be part of the solution, you can introduce a whole other world of opportunities. Tabular and conditional situations can be handled via user interface libraries and AJAX calls to web service endpoints.
We make extensive use of such techniques on our content creation and administration pages. For example, let's say an administrator wants to see a listing of users who are associated with a customer account. The request is handled through a web service endpoint and then displayed using a data table widget supplied by the Yahoo user interface library. Logic can be either offloaded to the web service by specifying parameters to the API call, or it can be dealt with by the administrator's web browser via JavaScript code.
The display of blog pages is handled by a different apparatus altogether. We have a web service that is dedicated to the rendering of blog page HTML. It knows about the types of content that can appear on a page, but it knows nothing about the customer's posts. That's stored on a completely different server. It also knows nothing about what a user has specified for display on a page because that is hosted on a different server.
When it's time to display a blog page, the service gets a bundle of data about what will be dropped into the page. It then fetches a template that describes the layout of the page and transforms the content into real HTML. To provide security on our end and simplicity for the page designer, we developed a template language that has limited looping and conditional constructs. It also has a tag set that is descriptive of the types of things that appear on a page.
We've been using this system since late April, and it has proved to be very flexible. We were able to not only migrate existing customers onto the system, we also introduced a second generation base template with a much better structure and styling design. Our product support team has been able to use the technology to ensure that our customers' blogs resemble closely the branding used on their primary websites.
Compendium is more than just affordable blogging software. We are providing a reliable service built on state-of-the-art web technology and best practices.
Comments for HTML as Code?
Leave a comment