Choosing a PHP Presentation Layer Technology

30 November -0001
by: Justin Klein Keane
May 28, 2006<

Smartly vs. XML

As a display layer, both Smarty (templating) and XML (transformation) present interesting opportunities and challenges to PHP developers. Both introduce exciting new possibilities, but careful consideration of client needs and maintenance requirements should guide your decision as to which technology to implement. The two differ quite drastically in conceptual framework and thus produce very different working results.

XML

XML presentation is rooted in the idea of translation to display layer. Thus, the logic layer produces an XML collection of the data and then an XSL style sheet is used to translate that data into proper display. This is quite efficient and gives developers a lot of flexibility in how to present the data, but this system is not at all approachable to non technical users. Web designers and authors often expect to find a page, or file, where the presentation layer resides, and using XSL this single concrete location is elusive. A user could examine an output page's source code, then hunt through the application files and never find what they were looking for. This is because the logic layer presents data in a transitory state, it only exists for the single page call. The output code is also transitory. Once prepared for the user and delivered it is lost. The only persistent data is the XML style sheet used for transforming the data, and it remains a set of instructions for the construction of output rather than an actual "template" that bears resemblance to the output. While some scraps of HTML might be found in the XSL file, the majority of the XSL could be XML translation instructions, which are meaningless to those without any foreknowledge of XML.

The counterpoint to this disadvantage is the fact that XML and XSL are widely documented and accepted standards that are free of platform. The technology is used across many platforms and systems and is becoming a near universal standard for open communication between systems. SOAP is the system often used for these inter-application communication, and it is becoming more widespread as the need to connect systems and network grows. Using XML easily enables SOAP and allows for a lot of flexibility in terms of interoperability with other systems.

Smarty

Smarty, on the other hand, is a templating system. It was designed with the web designer in mind. Smarty is founded in the idea that a template of raw HTML can be produced for most presentation pages, and that place holders for dynamic data can be marked in appropriate areas of the template and filled in by the logic layer during presentation. Smarty is designed to allow designers to utilize external authoring tools (like Dreamweaver) to access the template files (which are in fact valid HTML) and quickly understand the very rudimentary notation used to designate random PHP data.

Smarty successfully insulates the PHP data layer from the designer, allowing him or her to alter the look and feel of the display without fear of interrupting or breaking the logic layer. In this way developers can easy find a strict correlation between the presentation source code and persistent files in the applications file structure. This often times proves more intuitive to users.

Smarty does, however, suffer from the fact that it is a less widely used presentation and display technology. While Smarty is gaining traction in the PHP community, it does utilize it's own simple logic language and notations that are unique to Smarty. Both the PHP developer and the web designer are required to use this very specific language, which has only a narrow scope, in order to leverage Smarty. However, if application front end maintenance is to be left to external designers Smarty may prove to be the simplest presentation layer.

Problems

The problem of long term maintenance is present with both presentation layer technologies. Once the PHP development staff steps away from the project and business owners take over maintenance both XML and Smarty may present a challenge. Smarty is advantageous because designers can open templates in Dreamweaver and alter them as they see fit. This power, however, also means that they can remove or destroy the Smarty presentation tags if they are not understood. While the underlying logic would remain intact, it would be possible for a designer to render an application unusable by removing critical display components.

XML does not necessarily prove to be more robust in this respect. XSL technology is a bit cryptic, but is widespread enough that many users are at least somewhat familiar with it. Learning the basics of XSL takes little longer than learning Smarty tags, and altering XSL is a bit touchier than modifying Smarty templates. If an XSL is mangled, for instance by forgetting to close a tag, the entire display fails. Whereas using Smarty a designer can produce bad HTML and still preserve the actual page display, if the XSL does not validate then the entire display will fail with rather cryptic error messages. This functionality helps to insure that all XSL transformed documents result in strictly correct XHTML, which is important for information exchange, forward compatibility and standards compliance. However, the strict rules of XSL can be frustrating for an inexperienced user and mean that the display layer is somewhat fragile in inexperienced hands.

CSS to the Rescue

The best solution to the problem of fragility of display layers seems to be CSS. By utilizing strict, but plain XHTML display and liberal use of "id" and "class" within elements the page display can easily be created in such a way as to facilitate complete display control from within CSS. This solution requires that output display be carefully crafted, but the burden of design falls on developers rather than maintenance personnel. If the display information is grouped in appropriate div tags and elements are all strictly identified then it should be possible to control the display completely from within the cascading style sheet.

Using CSS also insures that designers are unable to 'break' the display layer. Malformed CSS won't actually obscure the display, it would only produce poor display. Also, by utilizing CSS for more advanced display applications can degrade gracefully based on browser support. Older browsers, while perhaps unable to display more advanced CSS elements, would at the very least be able to support the base HTML display layer.