May 2006 Archives

This is second part of the post. Find first part here.

So what is a better way of creating custom XmlReader/XmlWriter in .NET 2.0? Here is the idea - have an utility wrapper class, which wraps XmlReader/XmlWriter and does nothing else. Then derive from this class and override methods you are interested in. These utility wrappers are called XmlWrapingReader and XmlWrapingWriter. They are part of System.Xml namespace, but unfortunately they are internal ones - Microsoft XML team has considered making them public, but in the Whidbey release rush decided to postpone this issue. Ok, happily these classes being pure wrappers have no logic whatsoever so anybody who needs them can indeed create them in a 10 minutes. But to save you that 10 minutes I post these wrappers here. I will include XmlWrapingReader and XmlWrapingWriter into the next Mvp.Xml library release.

When developing custom XmlReader or XmlWriter in .NET 2.0 there is at least three options:

1. implement XmlReader/XmlWriter
2. extend one of concrete XmlReader/XmlWriter implementations and override only methods you need
3. implement XmlReader/XmlWriter by wrapping one of concrete XmlReader/XmlWriter implementations and overriding only methods you need

From .NET 1.X experience Microsoft seems finally figured out that providing a set of concrete poorly composable XmlReader and XmlWriter implementations (XmlTextReader, XmlTextWriter, XmlValidatingReader, XmlNodeReader) and emphasizing on programming with concrete classes instead of anstract XmlReader/Xmlwriter was really bad idea. One notorious horrible sample was XmlValidatingReader accepting abstract XmlReader instance and downcasting it silently to XmlTextReader inside. In .NET 2.0 Microsoft (with a huge diffidence) is trying to bring some order to that mess:

1. XmlReader and XmlWriter now follow factory method design pattern by providing static Create() method which is now recommended way of creating XmlReader and XmlWriter instances.
2. While not being marked as obsolete or deprecated or not recommended, concrete implementations like XmlTextReader and XmlTextWriter are now just wrappers for internal classes used to implement Create() factory method.
3. I was said that Microsoft will be "moving away from the XmlTextReader and XmlValidating reader" and "emphasize programming directly to the XmlReader and will provide an implementation of the factory design patterns which returns different XmlReader instances based on which features the user is interested.".

I've uploaded HTML versions of the XLinq Overview, XLinq Overview Diff (Sep 2005/May 2006) and XLinq SDK Reference to the XLinq.net portal. I don't fee it's right that I have to install heavy preview-quality package into my system just to be able to read these stuff. Or may be I just used to MSDN online. Diff is also cool for lazy/busy devs like me. Anyway. Btw, XLinq Overview link at the LINQ Project homepage points to the old September 2005 version.

Via Brian Jones we learn that the Ecma International Technical Committee (TC45) has published draft version 1.3 of the Ecma Office Open XML File Formats Standard. This is 4000 pages document specifying new (alternative to Oasis OpenOffice/OpenDocument XML format) Office XML format to be used by Microsoft starting with Office 2007.

As a matter of interest:

• The draft is available in PDF, which was created by Word 2007
• The draft also available in Open XML format itself, which one will be use once Office 2007 Beta 2 is out
• The document is huge and specifies everything down to the "Maple Muffins" border style kinda details
• These guys help MIcrosoft in creating Ecma Office Open XML format: Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, and Toshiba

Microsoft has launched CodePlex Beta - kinda revamped GotDotNet, based on Team Foundation Server:

CodePlex is an online software development environment for open and shared source developers to create, host and manage projects throughout the project lifecycle. It has been written from the ground up in C# using .NET 2.0 technology with Team Foundation Server on the back end. CodePlex is open to the public free of charge.

CodePlex includes the following features:

* Release Management
* Work Item Tracking
* Source Code Dissemination
* Wiki-based Project Team Communications
* Project Forums
* News Feed Aggregation

My experience with GotDotNet was a nasty one and I don't expect its successor to bring SourceForge quality any soon, but anyway CodePlex looks interesting and promising. It already hosts several interesting projects including CodePlex itself, "Atlas" Control Toolkit, Commerce Starter Kit, IronPython etc.

I'm sure my next open-source .NET related project will be hosted at the CodePlex.

LINQ May 2006 CTP installs C# 3.0 compiler and new C# language service into Visual Studio 2005. New syntax, keywords, Intellisense for extension methods and all that jazz. This essensially disables native C# 2.0 compiler and C# language service. If you installed LINQ on Virtual PC - big deal. But if not and you want to switch C# back to 2.0 - there is a solution. Folder bin contains two little scripts called "Install C# IDE Support.vbs" and "Uninstall C# IDE Support.vbs". Just run latter one and your native C# 2.0 is back. Somehow there are only scripts for C#.

I really enjoy seeing Michael Kay talking about working with XML in .NET. That makes me feel I might be not a freak after all.

According to Paul Vick VB9 LINQ query syntax will be switched from SQL-like "Select/From" to "From/Select" (Paul calls it "Yoda style" :) used by C# since the begining of LINQ. While for VB it's quite natural to follow SQL syntax (so not troubling poor busy VB developers), working Intellisense is more important. Anyway, I like it.

The changes should be in the next LINQ CTP, which is expected ... (wink wink) really really soon!

Here is one easy way:

1. Go to xmllab.net, get free eXml Web server control and modified Microsoft's WordML2HTML XSLT stylesheet, version 1.3.
2. Drop eXml control onto a Web form, assign DocumentSource property (WordML document you want to render), TransformSource property(wordml2html-.NET-script.xslt): <xmllab:eXml ID="EXml1" runat="server" DocumentSource="~/TestDocument.xml" TransformSource="~/wordml2html-.NET-script.xslt"/>
3. Create new folder to store external images
4. In code behind allow XSLT scripting and pass couple XSLT parameters - real path to above image directory and its virtual name:

   protected void Page_Load(object sender, EventArgs e)
   {
     EXml1.XsltSettings = System.Xml.Xsl.XsltSettings.TrustedXslt;
     EXml1.TransformArgumentList = 
       new System.Xml.Xsl.XsltArgumentList();
     EXml1.TransformArgumentList.AddParam(
       "base-dir-for-images", "", MapPathSecure("~/images"));
     EXml1.TransformArgumentList.AddParam(
       "base-virtual-dir-for-images", "", "images");        
   }
   

I had to add these two parameters so the WordML2HTML stylesheet could export images there and then refer to exported images in HTML. If you don't pass these parameters images will be exported into current directory - while that's ok when running WordML2HTML transformation in a command line, that's bad idea for ASP.NET environment.

Enjoy!