Introduction
Thanks to a lot of progressive education, web developers are starting to regularly practice three layers of separation (structural, presentational, and behavioral) in their projects and applications. Loosely assigned, XHTML builds the structure, CSS defines the presentation and JavaScript (for the most part) creates the behavior. This code segregation allows developers to create web applications that are organized, maintainable and reusable.
I believe, however, that a fourth layer of separation is being neglected: the data layer. This layer is represented by server side scripts that process and retrieve information from a data source. More often than not, we find this layer embedded messily into the structural layer. When the goal is to build modular architectures that are flexible and adaptable, combining structure and data processing is, in the long run, going to be very costly conceptual mistake. Through the use of a very promising XML technology, XSLT, we can free our data processing and retrieval logic from our display and structural logic completely and build web applications that are easier to understand and faster to iterate.
While none of the ideas in this article are particularly new, we believe there’s been a lack of attention brought to these topics (especially XSL) and since companies like Google are even using XSLT in their projects, we figure there’s a lot of developers out there who could use a look at how all of the puzzle pieces (web technologies) are starting to come together. For your convenience, we’ve also created a PDF of all the diagrams used in this article.
The Concept Behind 4 Layers
The only thing unique about the 4 Layers of Separation is the division of the Structure Layer into XSL templates and a set of server-side scripts to process information from the data source. Essentially, we want to allow structures or templates to be created or manipulated regardless of the data source or retrieval logic that will populate it. This is because we want to avoid embedding markup into a PHP script and vice versa. For example, here’s a simple script that populates and builds a table based on information in a database:
<?php
// Step 1 - Get any form fields needed for query
$username = $_REQUEST["username"];
// Step 2 - Build Query
$sql = "SELECT * FROM tAccounts WHERE accountName = '".$username."'";
// Step 3 - Execute Query
$rs = $cDB->ExecuteReader($sql);
// Step 4 - Display Results
echo "<table>";
while($row = @mysql_fetch_array($rs, MYSQL_ASSOC)) {
echo "<tr>";
echo "<td>".$row["username"]."</td>";
echo "</tr>";
}
echo "</table>";
?>
This is a simple yet typical way of how most scripts are written on the web and the problem here is that we are combining the handling of data with the HTML presentation of it. Changing how this data will be presented requires the server side processing and the HTML wireframes to be manipulated simultaneously because they are chained together in the code. This makes structural changes like showing the same data as an ordered list difficult and slow. In addition to that, steps 1-3 could easily become 50+ lines of code when you consider additional data processing tasks such as validation, security, etc. Now, let’s take a look at the same code written in XSLT to separate out the data layer:
<table>
<xsl:for-each select="Accounts/Account">
<tr>
<td><xsl:value-of select="username" /></td>
</tr>
</xsl:for-each>
</table>
Functionally, everything is the same. We are creating a loop and going through it to display the rows of a table. The difference here is that the processing and retrieval of data is nowhere to be found. This is the power of XSLT. It doesn’t care where the data comes from or how it is created. All XSLT requires is a properly formatted XML file (which would be created by your data layer scripts) to do its work. To learn more about XSLT, I recommend checking out Kevin’s excellent roundup on the subject. For the visually inclined, Kevin whipped up a little diagram to show how all of these layers come together.
Now, let’s break it down.
The Four Layers
Presentation Layer - The Presentation Layer is responsible for styling the way your elements look. Primarily focused on the aesthetics of your application, it is important to work closely with the Structure Layer for compatibility. This layer, however, does not involve manipulating markup. If you’re messing with XHTML, you’re messing with structure.
The most dominant form of this layer is CSS, but you can also substitute/integrate the visual effects of Flash into this layer as well if the ActionScript is separated out into external files.
Behavior Layer - The Behavior Layer is responsible for allowing dynamic interactions and real-time effects. Popularized by the recent Ajax fervor, this layer is receiving a lot more attention by developers. It is important to note that this layer must be integrated unobtrusively to be considered sufficiently separated from the other layers (like structure).
This layer is traditionally created using JavaScript, but feel free to also use ActionScript, JAVA and if you’re an IE fan, VBscript.
Structure Layer - The Structure Layer determines the format your data will be presented to the user. Most of the time this is XHTML, but you can also transform data to look like anything else (PDF, Word Document, vCard, iCal, RSS, TXT and even unformatted XML).
While the structural determination can be accomplished with server-side functions, this layer is best handled by XSL. By using XSLT, developers can cleanly delegate data processing to the Data Layer.
Data Layer - The Data Layer handles data coming from the user or from an outside data source. This layer is responsible for validating data, processing data and formatting data into a transportable format like XML (so it can be turned into markup based on templates provided by the Structure Layer).
Any server-side solution can be used to process this data (PHP, .NET, Python, Ruby, Perl, etc). And while the Data Source is usually a database (mySQL, SQL server, Oracle), it can also be an XML file, a text file, an RSS feed or even a Web 2.0 Service.
See It in Action
In an earlier article on The Hows and Whys of Degradable Ajax, I created a simple Todo List to demonstrate a modern web application that’s not dependent upon JavaScript. I’ve recreated the same application here, but I used the principles underlying the 4 Layers of Separation to build the code. You can see the demo and compare the source code files here:
How it Works
The approach to a 4 layers project is probably the most important part of the implementation. When you separate CSS and JavaScript out of the structure, you do so because you want a reusable file that is easy to edit and maintain. The same mindset applies to using XSLT to separate the structural layer from the data layer.
The easiest way to think of XSLT is as an include file. We’re all comfortable with creating a header and footer file that gets included on every page. You do the same thing with XSLT except you evaluate every include file in your document. Basically, if a section of our site will be dynamically added or removed via JavaScript, or if that section is bound to data, then we should convert it into an XSLT file.
Once we have decided which files the rule applies to, we can begin the conversion process. Remember, XSLT can display plain markup. Basically you’re going to open a file, add the XSL header, write plain XHTML inside, and then save it with an extension of .xsl. When you are first starting out, don’t think of an XSLT file as anything more than an HTML template document.
Binding Data
Just as you can put XHTML into any XSLT file, you can also mix in data with it. The only catch is that the data must be formatted as XML. So, you can pull data from a database, a web service, an ini file, or from a user as long as that data can be turned into an XML format. For a detailed look on how to convert information from a database into XML, see my tutorial on Database Simplicity - XML.
When you have an XSLT file, and a set of data you would like to associate with it, the next step is to perform a transformation. A transformation outputs XHTML which creates the structure of the page. Also, if you don’t have any data to associate to one of your XSLT files, you can bind it to a blank XML file. A blank XML file only needs to consist of the XML header and one empty node. The following function will perform the transformation.
function transformData($xslFile, $rs, $parentNode, $childNode) {
$xsl = new DomDocument();
$xsl->load($xslFile);
$input = new DomDocument();
$input->loadXML($cDB->ConvertRStoXML($rs, $parentNode, $childNode));
$proc = new XsltProcessor();
$proc->importStylesheet($xsl);
echo $proc->transformToXML($input);
}
Quick note about loadXML(): This function expects a string of XML to load, but if you actually have a physical XML file then just use load() instead of loadXML(). Other than that one line, the function is straightforward. It creates both an XML document and XSLT document, then it loads the stylesheet using importStylesheet() which then transforms the data using transformToXML(). After this function executes, you will see it display on your page. Let’s do a quick recap.
- Create XSLT files based on sections of your site.
- Build queries to associate with each XSLT file - use
blank.xmlif no data is associated. - Call
transformData()in the order you wish sections to display on the page.
Benefits of 4 Layers Approach
Easier to Develop in Parallel - The largest benefit that comes from the 4 Layers is that it separates most of the server side code out of the markup. This means that designers can edit the display of a page without ever having to look at what’s going on behind the scenes. Additionally, files stay just as reusable as an include would.
Ajax is Easier to Implement - In most Ajax applications markup is created in the JavaScript. This means that if the designer wishes to redo a section of a page, the associated JavaScript has to be completely redone as well. Using XSLT, we can dynamically change the display of a page based off of an external file.
Improves Database Queries - One thing that I have learned is that almost every SQL SELECT can be executed in one query. However, when I was first learning SQL I did exactly the opposite, which led to many recordsets looping within one another. Since XSLT files can only accept one dynamic XML file, you are forced to make sure you can retrieve all of your data in one query. This generally leads to more efficient queries.
Easier to Build Degradable Pages - With or without JavaScript, the page will be reading the same external XSLT file. This means your site will contain the same exact same markup with or without JavaScript.
Choose Any Data Source - You could easily connect to a different database with different table and field names and you would not have to worry about changing the code that displays the structure.
Limitations of 4 Layers Approach
XSLT - XSLT is a tough language. On top of that, complex equations become code heavy, and not intuitive at all. While tricks like working equations into your queries provide some benefit, XSLT overall is a problem in itself. This alone will discourage many people. Fortunately, this concept will work with any language that can transform XML, so substituting an alternative in the future won’t be hard.
Learning Curve - The fact that everyone on a team needs to learn XSLT is a limitation, but it is a limitation that I feel is acceptable considering the benefits. The ideal programmer should understand CSS and markup so that he can compliment the designers on a team (UI, visual, etc). And likewise, the ideal designer should create pages that are structured to help a programmer.
Speed - Using XSLT makes both Ajax sites and a non-Ajax sites a bit slower because the transformations have to be processed before being presented to the user. However, I have found performance degradations to be negligible so far. The ideal situation for dividing your development into four layers occurs while using Ajax. While it is a tad slower than pure JavaScript Ajax, this technique is still much faster than a normal refreshing web site and has all of the added benefits of the segregation mentioned above.
Server Load - Right now, dynamic transformations can’t be reliably performed on the client because different browsers support XSLT differently. No surprise there. Firefox and IE have completely different methods and Safari isn’t convinced yet:
Safari 1.3 and above supports XSL transformations of XML pages at load time. XSLT support is limited to XSL page processing instructions embedded at the top of an XML page:
XSLT not available via JavaScript for application to arbitrary XML in an HTML page.
Since there are no reliable dynamic client side solutions, I recommend doing all of the transformations on the server to ensure things work for the most number of users. This is fine for developers who do without the JavaScript fanciness, but on an Ajax site the potential server savings are sadly being missed. Google, however, is approaching the XSLT browser support problem with brute force by recreating all of the XSL transformation functions in JavaScript. This is why they created the open source project, AJAXSLT. We think their applications (like gmail) work like this:
The AJAXSLT JavaScript file will add about 90kb (fully commented and uncompressed) to your application. And while their implementation is faster than our degradable version (because it offloads the processing to the client), to make their projects degradable, they have to duplicate all of their functions both on the client and server side (which may be what they did to create the plain HTML version of gmail). We believe, however, that this is just a temporary solution for Google and that they (along with us) is betting on XSL support to just get better across the browsers.
Possibilities
Non compiled .NET - The inspiration for this project came from .NET code behind pages. They beautifully separate server side code from structure. My problem with them is that they need to be compiled, and the overhead in many cases is huge. This technique may lead to a similar setup without the need for a framework.
Eliminate Proprietary Templates - When you use your content manager, I am sure there are tags used to retrieve and display data. It would be nice if you could instead refer to a dynamic XML file, and use XSLT to display your data.
Browser Support - Client side processing would be a welcome addition. It would reduce the server load, and allow us to possibly switch to some form of REST or SOAP solution instead of a URL based solution.
In Summary
XSLT helps to provide another level of separation in web pages. Before the age of Ajax, a technique such as this hardly seemed worth the effort. It can result in a slower site with a higher learning curve. However, with more sites duplicating markup in both PHP and JavaScript, XSLT provides a nice compromise. It is a language that both JavaScript and PHP are able to understand, which removes redundancy.
Hi. Nice article, although I think that to talk about “4 layers” in the context of development might be confusing if you’re referring mainly to subsetting the presentational layer. Normally, only in the backend side of things you will find 3 layers (data-binding layer, business layer, controller layer). This is pretty common in Design Patterns specially in the Java world and increasingly in PHP with PHP5. 3 of the 4 layers you talk about refer to the “view” or presentational layer, when there’s actually many layers to the backend side only.
Ismael, the first three layers (structure, presentation, and behavior) I did not alter and kept to the commonly accepted naming standards. I was looking for a way to extract as much of the server side code from the markup as possible. That’s where the fourth layer comes from, and naming it was not easy. I called it the data layer because all it really does is validate, process, retrieve and secure data. I agree that the naming can become confusing though because the backend is already divided into its own layers.
What’s really the benefit of using XSLT? I’m having a difficult time understanding it.
Jason, lets say I have a list on a web page and it is populated with data from a database. All of a sudden my designer decides he wants to change the markup. In order to do so, he must hunt through php code that generates the list. That alone is not too big of a deal.
Now that Ajax is around, this list may be initially processed on the server. Then, list items can be added or removed with JavaScript. It is likely that people are embedding HTML as strings or using createNode to alter the DOM. This leads to redundant code that isn’t reusable.
With XSLT, both the server and client can talk to the same structural file. If my designer changes the list to a table, all he has to do is change one XSLT file, and nothing needs to be done to the PHP or JavaScript.
Jason, I’m responsible for a web application that currently uses this technology, except I do the transformation on the client side (prior to my arrival, it ONLY worked in IE. Now at least it also works w/ FF and others). Besides the elegance factor of separating the design from the data, it is quite practical, in that you can maintain an XML representation for your data on the server side, then give that same data many faces on the client via xslt. Different pages that display the same data in different ways both call the same server side api, but transform the data differently to suite each display. In my particular example, users construct documents from clauses, terms, and tables, but the data can be quite lengthy, and therefore awkward for the users to work with when displayed in its entirety. Our solution was to pull the full document xml from the server, then use two xsl transforms on the same data to create a two paned TOC|Content display. The data is only pulled once, and the page load doesn’t wait for the huge document. The toc xsl creates a nice nested list all linked up for navigation and control of the full content which displays next door.
nice concept.
Actually, it is done in the dot net world via datasets, datatables, data binding etc. so that you do not have to create a code spagethi of c# and (X)THML (although you can if you really want to).
On the java side things are a bit different. But there are frameworks for seperation: struts, hybernate to name a few.
I’m not familiar with the PHP side, so I don’t know whethere there are classes/frameworks for that purpose
None the less, I liked the idea of putting a structure layer in between. This may kina overkill for small-to-intermediate web apps. But it may be useful for enterprise-level development (such as fiance, insurance etc) where a lot of repots and table lookups go back and forth.
Than you for the nice article.
Yes! It’s great that you are advocating this approach.
One additional note that I’m not sure you covered: having XML coming from the server-side scripts makes it REALLY easy to do different layout thingies given different XSLT stylesheets; for example, generate an RSS/Atom feed, or do a mobile version.
Luke, do you use Google’s AJAXSLT to make it work in all browsers, or some other method?
I get it from the ‘design beauty’ perspective..
But does it really work for non-trivial situations e.g. a login page - how would propose dealing with the error handling involved with incorrect id or password?
It sure does. The login page for our store (along with everything else) was developed using 4 layers of separation. Pretty much, we’ll never have to design another login page again because everything is modular and completely reusable.
As far as error handling goes, I’ll leave that for Ryan to answer.
Great article.
There’s an interesting collision between 2 worlds here. The 3 ‘presentation’, ‘structure’ and ‘behavior’ layers belong to the realm of web design/web standards (clearly front-end layers). They are not necessarily well understood by hard-core web application developers (Java, .NET, etc…). Reciprocally, web developers are used to deal with 3 back-end layers (Model/View/Controller for instance) which remain a bit of a mystery to people coming from web design.
Anyway, I agree 100% with your approach. I use client-side XSLT in my projects when full cross-browser support is not required. The form builder (http://www.formassembly.com/form-builder/) works with IE & Firefox, and with the Time-Tracker (http://www.formassembly.com/time-tracker/) I managed to support Opera using Google AjaXSLT.
Things get slightly more complex with error handling, but it is still clean enough. You can set parameters in XSLT through either JavaScript or PHP. So, if there is an error, flag a certain paramter that represents that error. Then when the XSLT page is transformed, the error will appear.
To visualize this, go to the store. With JavaScript on in Firefox, purposely create an error. You should see a floating error message right above the form field. Now turn JavaScript off, and its just a generic red box on top of everything. When I am done working on the store, that generic red box will be gone and a floating error message will be everywhere regardless of JavaScript settings. Then, if Kevin decides he wants to change the look of the error message, he only has to change the CSS or the markup found in the XSLT file.
Nothing so fancy, I’m afraid. Just good ol’ fashioned code forking for now. My (intermediate) solution isn’t fully cross browser, I know. I just couldn’t bear watching the app fall on its face in FF. I’ll look into AJAXSLT.
Anyone know how to roll xsl and transformations of the sort in Rails or just Ruby itself?
Jon: Ruby has a number of libraries for doing XSLT. The only one I know of that’s still in development is http://raa.ruby-lang.org/project/ruby-xslt
(this is a shameless plug, btw)
Nice overview of the technique.
My team has been doing some similar work. We also decided to abstract the data source as a Web Service returning XML to the server side script.
$username = $_REQUEST[“username”];
please make sure that you are at least doing
mysql_real_escape_string($_REQUEST[‘username’]);
if you are only using mysql, because right now that’s a very bad sql injection vulnerability showed on the website.
Very good otherwise :-)
my two cents — David.
Thanks Brendan. I’m still trying to comprehend the concept. So then, I’m wondering, would I just output xml from Rails and then use the ruby-xslt to transform the xml to whatever I want? I really really like the idea of this 4th layer of separation, and XSL seems like a good idea to do this.
David - Thanks for pointing that out. I was just writing example code off the top of my head, but you’re correct — it is worth noting to readers that validation/security measures need to be taken.
Jon - I haven’t done it with Ruby, but you’ve got the process correct. Take data from your data source, and convert it to XML. Then, transform that XML with a XSL stylesheet. The transformation can be done on the server with something similar to ruby-xslt, or on the client with Google’s AJAXSLT.
Great writing Ryan,
Can you tell me where the ‘XsltProcessor’ in your ‘function transformData’ comes from?
Ellardus, it comes packaged with PHP5. It just needs to be enabled in php.ini. The PHP site has a list of the XSLT functions I use.
Great article. I love XSL. I’m more of a front-end designer/devloper who luckily stumbled into XML/XSLT about two years ago. I had to learn it to prove that I wasn’t just a “pretty pictures” person, and I’m glad I did.
One question, and maybe I read this wrong, but in the benefits section you said:
“Improves Database Queries - …Since XSLT files can only accept one dynamic XML file…”
Again maybe I read this wrong, but actually you can tie into another XML file inside of the XSL document, using the document() function (eg. ).
http://www.w3schools.com/xsl/func_document.asp
It’s a handy feature sometimes, but probably could get out of control if not used with restraint.
Whoops, my example got stipped out. No matter, it’s on the page I linked to.
Hilarie
Thanks, Ryan, for the interesting article. Ryan, Luke, considering client side XSLT transformation, what if your data is changed (say the record has been deleted or the new one has been created) and you don’t want to update your data source right away (only when the user is done with all changes? What would you do in this case? I appreciate your advice in advance.
maybe you should implement that error messaging on this form for comments : hehe.
anyway, this was a great read and i am interested in some more information. one question, do you have any good book recommendations on this topic?
thanks!
This isn’t exactly the same, might be of interest nonetheless. I’ve put together a tree control that uses “unobtrusive javascript” techniques, to seperate behaviour, style and content. There are a lot of other tree controls out there, but most of them use heavyweight, hard-to-configure code. I felt it was time for a change.
Some of the features:
Nate, can’t say I know of any books that are geared towards this. I’ve been learning through trial and error for the past 6 months, and it is slow going. For now, all I use are my JavaScript book, XSL book, and PHP book — and thencombine pieces from all of them.
Sergey - I am in the process of trying to handle that efficiently now, so I can’t be of much help yet. I’m looking at AMASS and playing around with it to see if it suits all of my needs.
Ryan, what book(s) do you use for Javascript, XSL and PHP? Thanks.
Just a quick note about Google’s AJAXSLT: according to the Google Maps documentation, the JavaScript XSLT processor is only used if the browser doesn’t have its own XSLT support. So you can use Google’s API on the client and still get full-speed transformations in browsers with support (like Firefox and IE), and the others will take the slightly slower road.
(You probably knew this, but the way it reads in the article makes it seem like Google’s API doesn’t use native client-side XSLT processors at all.)
Nick, thanks for pointing that out. I suspected that was how they did it, but was not positive.
Micheal - Defenitive Guide for JavaScript, Anything by Dan Cederholm for CSS/Markup, and PHP5 and MySQL for PHP
I prefer using Smarty templates and PHP instead of XSLT. I find they offer similar-enough functionality (essentially the .NET part mentioned) without being too obtuse.
Hi. This is not directly related, but your article got me thinking: most of modern CMS’s, specially blogging applications, already have a web service, XML formatted API so client code of any sort can interact with the common functions of the application. There’s just a bunch of these API’s which have become the standard for web publishing (the Blogger API is one). My question is: is there any XML standard for the publication itself? For example: most of these apps include their own templating engines and tags, but since most of them do similar things (publish posts, links, feeds, blogrolls, etc), wouldn’t it be wise to have a XML convention so all CMS’s would use it to publish content, so they don’t need different templating systems and you can just drop some XSLT to get your final interface? I mean, this way no matter what CMS you are using, as long as it complies to this XML publishing convention, the presentation layer would be truly and fully portable from one application to another. Of course it should at least extend RSS and describe all sections of a blog/site. Does such a thing already exists? Does it make any sense? Delete this if it’s nonsense.
Josh, Smarty is a good solution, but I found it lacking in two areas. I am not overly familiar with Smarty, so please correct me if I am wrong. First, XSL can pull from any data source as long as the data is in XML format. All I have to do in the PHP is change myfile.xml to yourfile.xml. I imagine you can set Smarty up to do this, but that would require manual processing of the XML. Second, JavaScript and PHP will be using the same exact templates, so that there is no redundancy. I am interested in learning more about Smarty though, so plan to research it further.
Ismael, I believe the CMS, Symphony, was going to make their templating system based off of XSL. I feel that is the most efficient way to go. Sure, the user has to learn XSL, and that learning curve may be slightly steeper than a common templating system. On the other hand, it would work as a common format in every CMS.
Other inconvinience about Smarty is that it is PHP-only. On the other hand, as long as your data is xml formatted, you can apply the same XSL to it no matter what server language. This leads me to explain my point better, Ryan: XSLT is used as a templating system by many applications and CMS’s, but I’m also talking about a standard XML format for blog pages, for instance, just like RSS is a standard XML format for newsfeeds. If you could rely on most of CMS’s to publish their pages in the same XML convention, you could apply the same XSL for design in a snap. No need to study the way that particular CMS handles templating.
Thanks guys for making the sourcecode downloadable :)
I managed to install it on my server, since the database structure wasn’t present I had to recreate it. Afterwards I dropped the session_start(); thing because the script will serve as an desktop application only for me ;) As a little bonus I extended the functionality so that you can make items ‘incomplete’ in the same way as making items ‘complete’.
The shown example is one of the best presentations handling this kind of scripts I have ever seen. Keep up the good work - Iam looking forward to see more of your work! :)
Ismael — I’ve been meaning to ask what you’ve been asking, what format the XML input files (being processed by XSLT) should be published in.
Might Atom 1.0 be the be-all, end-all publishing format? I’ve been reading the specs on the format, and it’d almost seem to satisfy the need for a standard, but extensible, XML format. http://www.atomenabled.org/ for more information.
Of course though, I know there is RSS and friends. Atom seems to stick out though, especially 1.0, as a creeping standard.
Any thoughts anyone?
Thanks for the great article. I’ve been using XSLT for financial business apps since about 2000. There is definitely a conception amongst back-end developers that it’s a very tough language to learn, but coming from a front-end XHTML/CSS background I found it very straightforward, with none of the hiccups, quirks and blatant oversights of CSS. The basic hurdle is getting over the recursive nature of the language, once you grasp that it becomes very easy.
I find using XML/XSLT a very handy tool for rapid iterative prototyping, as you can set up an underlying data structure once and build multiple modular views. Using client-side XSLT transformations, it’s possible to build up a fully-functional & portable prototype for things like demos and usability testing, with no need for an attached database.
A few things:
In your article, you mention that ASP.Net “code-behind” pages need to be compiled. This is no longer true with .Net 2.0, which is a great step forward.
For those learning XSLT for the first time, I highly recommend the Microsoft MSXML 4.0 SDK help files. They are very thorough, very well written, and as far as I recall, all the proprietary MS functions are broken out into a seperate section. This is what I first used when starting out with XML, and I was up and running in a few days.
Great article. The layer ideas are great . I liked the part that said that XSL is tough going. I have seen some XSLT generating java script, people need some direction out there! I have been programming for 15 yrs, and I must say it was the most difficult language to learn (I call XSLT the end users revenge on programmers! finally they have a language to confuse us! Interesting how different mind sets think.
Anyway great article.
mike
Hi,
I tried your Todo List Demo in FF 1.0.7 but, with or without javascript, it show this kind of errors:
Warning: mysql_connect() [function.mysql-connect]: Access denied for user ‘particle_web’@’particletree.com’ (using password: YES) in /home/httpd/vhosts/particletree.com/httpdocs/examples/degradableajax/cDatabase.php on line 93
What’s the matter?
Great article.
Ale
Excellent article. I just disagree on one point… well… not necessarily disagree but… XSLT is actually quite fast. I worked on a project a few years ago (you know… before AJAX was called AJAX :P) which used xmlhttprequests and xslt’s for display. One of our reports had to parse through something like 10,000 records in one shot. We assumed that it would be faster to do it simply in Javascript. Wrong. The XSLT parsed it in less than 3 seconds, whereas the Javascript took something like 15.
The details are kind of funny as this was about 3 years ago, but anyway my point is that for large data transformations… XSLT is amazingly fast.
XSLT is just amazing in general.
Excellent article. I just disagree on one point… well… not necessarily disagree but… XSLT is actually quite fast. I worked on a project a few years ago (you know… before AJAX was called AJAX :P) which used xmlhttprequests and xslt’s for display. One of our reports had to parse through something like 10,000 records in one shot. We assumed that it would be faster to do it simply in Javascript. Wrong. The XSLT parsed it in less than 3 seconds, whereas the Javascript took something like 15.
The details are kind of funny as this was about 3 years ago, but anyway my point is that for large data transformations… XSLT is amazingly fast.
XSLT is just amazing in general.
Tyler - once you have an XML file, XSL can parse it quickly. In my workings with this technique, I have found a couple performance problems:
1) PHP pulls from the database and the writes the results in XML format. XSL parses the XML, and echos the response to the client. The clients Ajax request then places the result in the DOM. This part went faster just embedding markup into the PHP and echoing it out, but the separation was lost.
2) Client side XSL processors were much faster than server side. If the application does not need to be degradable, then I would go this way because the performance was great.
It is good to hear XSL being used ni large projects and keeping up performance and stability. I am a fan of the technology, and would like to keep using it more.
Great site. I will bookmark for my sons to view as well!!!i
Hi! Very nice site! Thanks you very much! lgcNbxQGbU
http://prlncdqkrym.com
Cool!.. Nice work…i