We built the Data View on XSLT for a couple of important reasons:
1) We wanted there to be a “real” programming language under the covers, so that our users would never be limited by what our UI allowed, i.e. even if FrontPage can’t do something, you can always jump into code view and still solve the problem.
2) The very nature of XSLT, being a declarative programming language, made it possible for us to ship one of the richest design experiences out there for building data-driven views. In the most tools (at least any I’ve seen :>), the experience you have building the view is very distinct from what you get using at the view. At best, the design surface show you a very rough approximation (typically schematic) and any editing is done through intermediate tools, e.g. dialog boxes, code view, etc. With the Data View, thanks to the power of XSLT, we were able to deliver a no-compromises experience, where you always see the exact end product and editing works like you’d expect it to.
Example: To highlight the difference between most view building tools and the Data View, let’s compare what it’s like building a simple view of the SQL Northwind Products table using the Data View vs. the the ASP.net Grid View. Note: although I’m picking on the Grid View is this case, this comparison is valid for most app building tools out there.
Here’s what the ASP.net Grid View looks like by default against the Northwind Products table:
As you can see, the Grid View uses sample data, not the real data, meaning the editing experience is different from what you get when you preview the page. You also can’t directly format the view, i.e. you can’t click inside and start editing. If you want to change the way the view works, the Grid View supports some amount of formatting using the “Edit Fields” dialog, but if you want to do anything really fancy, you’re in the world of templates or .net code.
Contract that experience with the same table in the Data View:
Not only do we show ‘live data’, but you can also directly format the presentation of your view just like regular page editing. E.g. in the picture above, I was able to make the first column bold simply by clicking inside and pressing the bold button.
How it works: In previous posts, I explained that XSLT allows you to take an XML document and transform it into an HTML presentation. The magic of the Data View is that it allows you to go in the opposite direction – FP shows you the “transformed” HTML in design view and makes it look editable, pretty much like a regular table. However, under the covers, instead of mapping edits to html changes, your edits get translated by FrontPage into XSLT changes, which is what you’d see in code view. E.g. in the above scenario, when I made the product name bold, FrontPage figured out what part of the XSLT defined the product name, and wrapped the tag (in this case, an <xsl: value-of> ) with a <strong> tag. Of course, you can also go the other direction, edit the in code view and have us reflect those changes in design view.
This mapping of HTML edits to XSLT edits is what makes it possible for us to provide our great editing experience. And although the technical explanation is rather complicated (and frankly a bit above me :>), it’s only possible with a declarative programming language like XSLT, where a program like FrontPage can truly “understand” how to read and write “code”. One of these days, I’ll interview one of our devs and get the “real” technical explanation for y’all :).