Every organization from the one-man outfit to the corporation with 10,000+ employees uses worflow at some level. It keeps a structure around production or services or products (or in our case, content). It enables administrators and managers to audit individual or team activity, and creates accountability. Workflow is essential.

Although I’m not going to discuss the technical details of how to implement workflow automation in your CMS (some of my best trade secrets would be revealed if I did!) I will tell you that it’s the cornerstone of a good CMS system. Whether you’re purchasing a CMS from your contracted webshop, purchasing something off the shelf, or developing for your own in-house or client project use, workflow automation must be at the foundation. Without good workflow automation, tasks which would be trivial become headaches. Data integrity becomes impossible to maintain, and quality will suffer.

There are plenty of CMS systems out there with advanced workflow automation built in. Some of the better open-source CMS systems utilize workflow automation, so you could - if you so desired - open them up and look at how it’s done. A good workflow automation CMS will include the following:

• A multi-user architecture
• User-specific & Content-specific auditing.
• Content locking
• Role-based permissions system
• Content versioning
• A system of failsafes to preserve data integrity - Example:
  (Deleting a product from the catalog might cause problems for users viewing orders for that product placed before the deletion. Maybe the deleted product was a related product for some other product. The relationship might still exist although the product does not.)
• Automated data backup and recovery

Building or purchasing the right workflow automation CMS system will dramatically improve the efficiency of your organization. If you’re a webshop, offering workflow automation to your clients is a huge upsell. If you’re doing it properly, it’s a build once, use everywhere solution, which can help you avoid selling the one-off solutions which makes us developers cringe.

If you’re writing ASP.NET code in Visual Studio, then chances are you’re using “code-behind” modules. When using a code-behind, your code is almost completely separated from your display logic. In some instances,  you need to make a logical decision at render-time, but generally, the only code you have in your HTML is HTML and CSS. When you build your ASP.NET project, you get a DLL and a matching HTML (.aspx) file. In ASP.NET 1.x, the HTML file was always going to be human-readable and looked the same before and after the build. In ASP.NET 2.0 (assumed in 3.0 as well) you can configure your build to create an HTML (.aspx) file which is only a placeholder for the browser. All of the display logic is also compiled into the DLL. If you ask me, I don’t like it, but it does help when you’re selling your code. Compiling everything into a DLL hides the original ASPX source code.

In PHP, you need to be a bit more dilligent with removing code logic from display logic. There are more than a couple handfuls of good templating engines out there, which allow you to “interpolate” variable values in your HTML code, and keep your PHP code completely separate. I’m partial to XTemplates myself, because they’re simple to use.  For each page the user sees, I’ll create two files (not including a default header.php and footer.php): MyPage.php and MyPage.tpl (.tpl tells me it s a template file). I’ll generally keep the tpl files in a <current dir>/templates directory, and leave the PHP where it should be. The .tpl file contains nothing but HTML and the template specific notations.

The version of XTemplates that I use is probably old, but I love how it works, and it works well, so I’m not changing. I’m sure the concept hasn’t changed much, even if everything else has. Here’s how XTemplates works:

[PHP]

<?php

//assumed inclusion of the xtemplate library
$tpl = new XTemplate(’thetemplate.tpl’);

for($i = 0; $i < 10; $i++){
   $tpl->assign(’theNumber’, $i);
   $tpl->parse(’main.listItem’);
}

$tpl->parse(’main’);
$tpl->out(’main’);

?>

[HTML]

<!– BEGIN: main –>
<html>
<body>
   <ul>
       <!– BEGIN: listItem –>
       <li>{theNumber}</li>
       <!– END: listItem –>
   </ul>
</body>
</html>
<!– END: main –>

[Output]

• 0
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

It’s simple. The PHP code runs a for loop. Each time through, it assigns $i to the “theNumber” variable in the template. It then “parses” the <li></li> block (main.listItem) and repeats. After the for loop, we “parse” the “main” block -> which contains all of the main.listItem generated text). We’ve now got all of our HTML text in the output buffer, so we send it to the browser with $tpl->out(”main”); That’s not too difficult.

This example shows you how clean your HTML and PHP remain when separated from one another. It also gives the page production team the ability to write HTML without having to manipulate PHP code, and gives the coder freedom to write code without being bothered with HTML (although they should know HTML - but that’s another post).

I’ve only touched on PHP and ASP.NET here, but I know your platform of choice offers some method for splitting code and display logic. Using this style of development will improve readability, writeability,  performance, and development time.