Those involved with application infrastructure have always searched for the holy grail of separation between business logic and design. The idea is that most, if not all, projects require many different people to complete--from project managers to designers to programmers to quality assurance testers. Unless you're working on a one-man project or a hobby, chances are there is more than a single person that needs to get his or her hands dirty.

When it comes to applications themselves, it is most often the case that both programmers and designers have to touch the source code. Usually these jobs are not interchangeable, and each has his or her own unique skills set. As applications evolved to become more complex over the years, static web sites and applications gave way to dynamic rendering. Web browsers still only interpret markup, however, so it is often up to the application to generate that markup. With early applications this often meant something like Perl scripts rendering HTML from within the script itself. Even with a more popular language like PHP, with the early applications, HTML was often rendered and mixed with other programming languages, and it was the back-end, dynamic programming language that was handling that output. With languages like Java and C#, this meant presentation layer changes required a recompilation of code.

Rendering HTML from the back-end--inside of code--creates many terrible scenarios for both designers and programmers, and later languages attempted to remedy this by providing an early version of what would eventually evolve into the Model-View-Controller (MVC) concept. Java developed Java Server Pages and Servlets. Microsoft had Classic ASP, while evolved into ASP.NET. PHP techniques started shifting towards using external files to power more design-oriented files. With these technologies, front-end pages focused on HTML with special tag syntax for applying dynamic content. Later technologies pushed the separation of presentation and programming even further apart with a more refined MVC approach. Ruby on Rails, Django, web.py, ASP.NET MVC and others took a stricter approach to the separation of data models, view pages (design), and controller files (business logic).

Although each has its advantages and disadvantages, the truth is that each also still relies on some form of programming or programming tags in order to process dynamic content. For example, to create a dynamic listing in Django, you would do the following:

{% for post in posts %}
        <h1>{{ post.title }}</h1>
        <div>{{ post.content }}</div>
    {% endfor %}
    

This code loops through an object relational model (ORM) collection of posts, displaying the title and content of each. This would reside in a template file in a Django project (Django's version of the "view"--they use different terminology). This means that this code resides in a file filled with HTML that would normally be used mostly by designers. Notice the specialty syntax embedded within the code snippet.

Now Django does its best to limit the amount of code in HTML. In most instances, it prevents programming, and only has this special syntax for accessing and displaying objects. Other programming languages aren't so lucky. ASP.NET allows you to use large amounts of programming logic in ASPX pages, even if you have a code behind page. Even ASP.NET MVC with Razor allows one to litter HTML markup with programmatic syntax. With Node.JS, and any one of the multitudes of JavaScript libraries/frameworks that allow for templating (there seems to be a new hot framework each day), you might be able to have MVC that fits in the wheelhouse of a front-end designer, but bear in mind that not all web designers want to program JavaScript--or program at all. In fact, even those that can, probably might not be adept at it enough for you to leave the fate of your web application in their hands.

There is another that many will dismiss are crazy, but upon closer examination, might just be the best way to do MVC that gives complete freedom to designers, and complete separate of data from business logic and from design. That way includes XML and XSLT.

We've already seen how XML can be an ideal data format that not only accurately marks up a representation of the data, but allows for ancillary descriptive information through attributes, validation through schemas, and extensibility through namespaces. Properly structured XML can inform designers on the context of the data, allowing for better usage in design. Furthermore, programming to an XML representation allows for a programmer to focus on the data and business logic, while leaving the design considerations to those more qualified.

When I worked at Barbella Digital, all of our data objects culminated in what we termed an "Info" object. You can imagine this Info object to be an ORM representation of our data. It works a bit like this:

DBActive.Contact.Info.Person_Collection people = DBActive.Contact.Data.Person.Select();
    

We use a version of three out of the four part naming schema in SQL, so DBActive is what we term the "Active" database. The database name might be something like "Barbella.Active." The second portion represents the schema name. In Microsoft SQLServer, dbo is the primary schema, but you can create as many as you want. At the time, we liked to group related database tables through a schema name. The third part is a signifier for the code, it could be DO, BO, Info, or Data. DO and BO are parts of the data object framework that represent data logic and business logic respectively, and are often never accessed because of an static abstraction layer (Data) that gives shorthand access. Info, meanwhile, is the constructed ORM. The final part represents the table data. In this instance, we have a Person_Collection, which is a collection of individual Person Info objects. You could iterate over them like so:

foreach(DBActive.Contact.Info.Person person in people)
    {
        Console.Write(String.Format("{0} {1}", person.NameFirst, person.NameLast));
    }
    

If we only needed to select a single record, we could do so by passing the Select() method an ID or GUID:

DBActive.Contact.Info.Person person = DBActive.Contact.Data.Person.Select(1);
    

In this case, "1" is the record ID.

What's important (and relevant) about this is that all of our info objects (and info collections) have a ToString() method that converts the data to an XML representation of said data (as a string). This means that all data can be immediately represented as XML anywhere in an application.

What does this mean for MVC? A programmer will more than likely be programming to this point of the data, while a designer will take that data and make it look good in HTML. The missing ingredient is XSLT. Most programmers seem to be afraid of XSLT, but that really comes from a lack of understanding, and a failure to mentally switch to a tag-based programming language.

Let's imagine a list of posts like in the Django example. The data might look something like this in XML:

<Posts>
        <Post>
            <Title>Advanced XML Strategies</Title>
            <Content>...content here...</Content>
        </Post>
        <Post>
            <Title>A Brief History of XML</Title>
            <Content>...content here...</Content>
        </Post>
    </Posts>
    

This data will then be transformed on the server and pushed out to the web site, or in this asynchronous, disconnected web world, you could push the XML out to the client and run the transform there. The latter is more valuable for pages with multiple areas of dynamic content that run disconnected.

The transformation can be something complex or something as simple as:

<xsl:for-each select="/Posts/Post">
        <h1><xsl:value-of select="Title" /></h1>
        <div>
            <xsl:copy-of select="Content" />
        </div>
    </xsl:for-each>
    

At first glance this may seem more complex than the Django example, but this follows all the rules of tag-based languages. Any designer who is comfortable working within HTML, will easily be able to work within the confines of XSLT. You wouldn't task a designer with building out the XSLT code--a programmer would do that, but the designer would easily be able to work within the file to add the appropriate design elements without having to wade through code that is distinctly different from what they are used to. There aren't special syntax characters or additional programming language code to root through. Instead, there is a very basic tag syntax that follows the same principles as HTML, and XML is parsed for transformation using a very fundamental pathing syntax called XPath. At its most fundamental, XPath is a simple way to walk the DOM tree--easily understood by non-programmers--but can be very powerful in the hands of a programmer.

Done correctly, all data and business logic (i.e., programming) occurs prior to the transformation. The XML data ultimately represents the end result. This means that XSLT does not need to be used as a full programming language, but only as a way to navigate and shape data, limiting any potentially confusion or complex transforms; however, it's always nice to have that additional power available if needed.