XSLT in the .NET Framework: Data Binding and Control Creation at the Same Time
Until I am capable of finding myself incorrect, I maintain that Microsoft pushes so hard away from XSLT alternatives to data binding and control creation for ASP.NET Web applications and the “smart client” because most Microsoft developers see no advantage in XSLT-related .NET technologies over binding to controls. Most Microsoft developers are historically and irretrievably devoted to binding to controls. Indeed, I have enjoyed this rich tradition since Access 97. But when the Internet came, I embraced the teachings of the W3C. This means that finding standards-based, platform-independent solutions is a real and present priority. With this W3C “wrench” thrown into the works these ideas pop out:* Almost all of the user interface elements of a Windows Forms 2.0 “smart client” can be rendered in the WebBrowser. This investment is designed to be platform independent and can be reused in a server-side Web application.
- XML representations of data are first-class citizens. There really shouldn’t be any sentence following up as a defense of the previous one. Many .NET developers simply do not “like” XML.
- JavaScript plays a major role in client-side business logic. This sentence is laughable for many .NET Windows Forms developers—and we can probably get a chuckle from the hordes of ASP.NET developers who avoid writing JavaScript by using the great features in ASP.NET controls. The promise here is that an XSLT-based “smart client” is almost a client-side web application. A “real” server-side Web application is only needed to serve fresh REST or SOAP data for our ‘first-class’ XML.## A Prelude to XAMLMost Microsoft developers are historically and irretrievably devoted to binding to controls procedurally at “design-time” in a visual IDE… However, the power of developing a User Interface declaratively is not ignored by the vast material and intellectual resources of Microsoft. The Windows Presentation Foundation of Windows Vista is the Microsoft vision of this future.
So I hear Microsoft saying XAML is the platform-specific alternative to XForms. I think I hear Microsoft saying that InfoPath (which is not based on XForms—it is a COM heap of XHTML and XSL) is only a temporary stopgap measure until XAML gets going…
Comments
Eric Richards, 2006-03-08 00:27:28
Disclosure: I work on InfoPath.
InfoPath is by no means a stop-gap measure awaiting XAML. In some ways, it's too bad that Microsoft has so many different technologies for doing similar things (e.g., forms) but it's better than coming up with the uber-form package that probably is so complicated and full of comprises that it pleases no one.
InfoPath is super-appropriate for the Enterprise environment, especially for people already with the Office Pro Enterprise license. It's in there.
With Office 2007, we have the Forms Server for filling out forms in IE or Firefox. And the InfoPath rich-client control is now hostable (yay COM!) showing up in more and more products like Word, Excel, and PowerPoint. And we have a fantastic Outlook integration story.
XAML and Office? That's not on my radar. But right now I'm focused on getting InfoPath 2007 wrapped up, polished, and exploding out of the door.