Perhaps the first commonly-used example of an AJAX (asynchronous JavaScript and XML) application was Outlook Web Access, which has saved me on more occasions than I can remember. AJAX gives OWA the ability to provide a much richer experience than would otherwise be possible, with postback-free retrieval and display of email messages and other Exchange objects). Other more recent exploitations include Google Maps and Google Suggest, both of which push the browser model to new heights. AJAX will never support the kinds of visually differentiated applications that Avalon will enable, but as a platform-neutral model that alleviates some of the most painful aspects of web applications, it's a very interesting model.
One of the greatest drawbacks of AJAX is that it's simply too hard to code. The very fact that I can count the number of truly exploitative public AJAX applications on the fingers of one hand is an indication of that. What's needed are toolkits and platform support that can abstract some of the plumbing work and enable developers to focus on implementing the application itself.
I'm delighted therefore to see that the cat is out of the bag on Atlas, a series of components for ASP.NET that simplify the process of building AJAX applications. Atlas will include server-side controls that handle the async callback process, client-side web service access, a local cache, and client-side access via web service to the ASP.NET 2.0 profile and membership services. This latter capability could also be interesting in combination with an Avalon Express application, which could take advantage of some of these services to share the same back-end infrastructure as an ASP.NET application whilst integrating richer functionality.
More on Atlas at the PDC, of course!
At TechEd this year, many of the Microsoft Regional Directors recorded short ten minute technical presentations on their favourite technologies. If you've not come across the RDs, they're a smart bunch of independent developers and architects, most of whom make a living training and consulting on .NET. They include luminaries such as Carl Franklin (founder of .NET Rocks), Clemens Vasters (author of dasBlog), Rob Howard and Scott Watermasysk (authors of Community Server, the blogging software that runs this site), Juval Löwy (author of one of the best books on .NET Components), and Scott Stanfield (responsible via his Vertigo company for perhaps more .NET sample apps than anybody else in the world).
Anyway, about twenty of the RDs volunteered to record GrokTalks: no spin, precious little Powerpoint - simply a quick code-based intro to an emerging technology. They're great for downloading onto your laptop ready to play during an idle moment when you need to fill a gap or just need a mental break from whatever you're doing. Here are some of my favourites:
The full list is online at GrokTalks.
Metro is a suite of new document and print infrastructure technologies that are embedded in Longhorn and WinFX. I wrote about Metro in the Avalon Beta 1 RC guide, but in brief Metro provides a standardized ZIP-based document container and open document format, a new print pipeline and spool format, and a file viewer that supports fixed format documents. If you ever want to print or save a document in Avalon, or you want to create a portable file that can be viewed on a machine that doesn't even have your application installed, Metro is the technology for you. In preparation for a Channel 9 interview I'm conducting tomorrow with one of the architects in the Metro team, I've been spelunking through the object model to try and build a few small samples, and it's so cool that I wanted to share what I've got. Everything below runs with the published WinFX Beta 1 RC bits, available for download from MSDN (make sure you install the SDK if you want to build this stuff).
Download the full code sample here.
Creating a Metro file using WinFX just requires a few lines of code, and once you've created it you can print, save, edit at your leisure. Metro revolves around a ReachPackage object, which describes the container format, and is in turn created from a ZipPackage, which is simply a .NET representation of a ZIP library. ReachPackage exposes a number of methods such as AddReachFixedDocument, which allows you to work with fixed documents directly; it can also be used in conjunction with Avalon with a PrintableArchivableDocument object, which can write any Avalon visual to the ReachPackage. The following code fragment shows how this works:
Package package = ZipPackage.Open(@"c:\test.container", FileMode.Create); ReachPackage reachPackage = new ReachPackage(package); PrintableArchivableDocument pad = new PrintableArchivableDocument(reachPackage); pad.Write(MyDocument);
To test this out, I created a TextFlow object in XAML - since this derives from Visual, it can be used as the parameter for the PrintableArchivableDocument.Write() method.
This creates a file called c:\test.container, which you can open on any machine with the WinFX Beta 1 RC installed, and see what it looks like using the Metro file viewer.
click to enlarge
Another thing you can do with Metro is to add your own arbitrary parts. For the purposes of demonstration, the following code fragment adds a small HTML test file to the Metro container, but in practice this could be your application's own proprietary data stream.
PackagePart part = package.CreatePart(new Uri("/test.html", UriKind.Relative), "text/html", CompressionOption.Normal); // this is where you'd write your data using (StreamWriter sw = new StreamWriter( part.GetStream(FileMode.OpenOrCreate, FileAccess.Write))) { sw.WriteLine("<HTML><HEAD><TITLE>Metro Test</TITLE>" & "</HEAD><BODY>Custom data</BODY></HTML>"); sw.Flush(); }
Even cooler, you can actually rename this .container file to a .zip extension, and then you can see its contents and indeed work with them. Everything in the container is fully documented as an open format - see the specification. This is the same container format as Office 12 uses, so if you create your own applications to use the Metro container format, then any application that understands the Office format will be able to work with your application natively. Remember too that you can embed all kinds of metadata in the Metro container header, such as digital signatures for example.
It's a shame that we have to produce an installation guide to help developers get the various required components for Visual Studio Team Foundation Server up and running, but that's one of the vagaries of beta software. It's clear that not everyone is familiar with this installation guide, so I'm linking to it here. It describes the order of installation, accounts that need to be created, how to manage security on the server, and how to deploy TFS in a distributed server environment.
Just to add to the fun, when I downloaded this guide, it didn't allow me to view the pages of the CHM by default on my Windows Server 2003 box because of the heightened security settings in this environment. If you get a browser error page when you open the help file, right-click on it and choose Properties, where you'll find a setting that allows you to unblock active content:
Once you apply this change, everything should be good to go. Hope this helps - it's worth it in the end, as the Team Foundation Server capabilities are a fantastic addition to Visual Studio (well, I would say that, wouldn't I? :-)