TCA and Design Time Scripting (DTS)

On today's internet there are two main ways web pages are built and maintained. There are static web pages (the vast majority) and there are dynamic, data driven pages created with such technologies as ASP, JSP and Servelets.

Dynamic pages offer significant advantages over static pages because there is a separation of content from presentation. If you change the database, those changes are reflected immediately in the web-site. In effect, the web-site doesn't actually exist in the same way a static page does. A dynamic page is created each and every time someone asks to see it and then it is discarded.

But dynamic pages have drawbacks too. They are usually much harder to produce and maintain than static HTML pages. Usually it takes a team of expensive developers to build a data-driven web-site. Dynamic pages require advanced programming and database skills to build and take more time to test and get running the way they should.

Furthermore, dynamic pages suffer from a mish-mash of technology. HTML pages are hierarchial and element based and there is a Document Object Model (DOM) that allows programmatic control over this element hierarchy. But the DOM is not available to the technology that builds the dynamic page (such as ASP or JSP). Instead of a hierarchy, dynamic pages are produced using a text only (stream-based) system. This means that all the convenience of a DOM is thrown out the window.

And if a page isn't changing on a second to second basis then why should it be updated each and every time somebody wants to view it anyway? This doesn't seem to make very much sense.

And so we come to DTS, which offers a new conceptual framework for data-driven web-sites that want the best of both static and dynamic pages.

DTS works with both streams and the DOM to give you complete flexibility in how you want to build a dynamic document. For example, the following are (almost) equivalent:

// DTS
dts.writeln("Hello from DTS!");

// ASP
Response.WriteLn("Goodbye from ASP");

But DTS also allows programmatic control over the DOM well. For example to set the title of a page in DTS and ASP:

// DTS
document.title = "Hello DTS!";

// ASP
<title><%
Response.Write("Goodbye ASP...");
%></title>

Because ASP is entirely text-based, an ASP tag must be added inside the <title> element of the HTML document. But setting document.title on the DOM will do exactly the same thing. So what would you rather do to make the document's title dynamic?

The capabilities of DTS extend to any aspect of a web page. Here is code to colour each second row of a table:

// DTS

function stripe_table(tab, color)

{

   for(var i = 0; i < tab.rows.length; i++) {

      if((i%2) != 0)

         tab.rows[i].style.backgroundColor = color;

      else

         tab.rows[i].style.backgroundColor = "";

}
}

Once you have this function, any table can then be striped with the following DTS:

var table1 = document.getElementById("t1");
stripe_table(table1, "#EEEEEE");

Used this way, DTS becomes a way of imposing constraints on the page. The designer decides that a table show be striped to improve readability and they add DTS to do exactly that.

Six months pass and the page is updated by somebody else who deletes a row from the table but forgets to change the background colors of the surrounding rows. A problem?

No, since DTS will re-stripe the table, leading to a correctly striped table, regardless of the changes within.

You might be wondering how DTS works and how it is different from straight DHTML. After all, you could accomplish the same table striping with a client side script.

As the name implies, DTS executes at design time compared to run time (as with client side script). This leads to three benefits.

First, the changes are actually visible in the editor. This means that there are no hidden surprises. When you work on surrounding content, you can see exactly how the final page will look after the DTS has executed.

Second, DTS will always execute. Client side script on the other hand might not. The target browser might not support script or the user might have turned script off. DTS only executes on one machine, your machine, where you know exactly what kind of environment it's going to run in.

And finally, since DTS runs on your machine this means it can access any databases that you can connect to in a confidential way. There is no way that an end user could know that you used the password "open sesame" to access a database that built a table that you generated with DTS. The DTS script is not included in the final page, only it's effects.

DTS is an ideal solution to the problems of dynamic and static pages since DTS is both of these things and more. Using one-click maintenance, you update your website with DTS and then upload it to the website each time you want to make an update. Alternatively you can schedule automatic web-site updates with Windows Scheduler.

In between updates you can leave your databases in an inconsistent state without worrying that your changes will be shown on your production system. Furthermore, your databases are kept safe on your local machine without the possibility of being compromised by hackers breaking into your web server (a regrettably common occurrence).

The single limitation to DTS is that you still need ASP or JSP to receive information such as form results. And if your web-site is changing frequently more frequently than you would like to update via FTP then you might want to look at a combination of DTS and the auto-ASP generation facilities that TCA offers.

But if your web-site is like the majority that changes weekly, monthly or yearly then TCA and DTS offer a great solution for building and maintaining web pages.