Over this past weekend, the XSLT Timer tool has been released on Code Gallery.
This is a very simple tool, that will simply allow you to type / paste in a document and an XSLT stylesheet, and then tell you how long it takes on average to do the transform using the XslCompiledTransform class. Very simple, but handy when trying ad hoc variations on ideas and such.
You might want to look at the XML Resources page for links to other tools as well.
Enjoy!
update #1 - adding an actual link to the tool helps :)
There's a fascinating look at Microsoft's history, year-by-year, on Channel 9. I hadn't looked at these before, but they're relatively short so you can view them whenver you have a break and come back later.
Looking forward to more of these.
Enjoy!
I've written about performance tools in the past - it's a topic that interests me quite a bit, because I believe that perceived performance is a very fundamental part of the user experience and can wow you or frustrate you immensely. And I believe "real performance" (so to speak) is very important of course, especially when you don't have a person sitting in front of the computer, but I think every developer will appreciate the difference that a 2' checkin script has vs. a 20' checkin script or a 60' script. 'Nuff said.
In any case, this post about Visual Studio 2010 profiler tools shows some fabulously productive stuff. And all with Visual Studio usability, rather than what it feels like to use some of the more arcane tools (that are admittedly very well suited to automated scenarios, we'll always grant them that).
Anyway, read up and enjoy!
One other twist on the last slicing stylesheet. Let's say that we didn't want to hard-code the number of items in a group, but instead we wanted to be able to control this separately. We can use an xsl:param on the stylesheet to control this externally and provide a default as well.
Here is the touched up stylesheet, with the changes highlighted.
<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
<xsl:output method='xml' indent='yes'/>
<xsl:param name='itemcount'>2</xsl:param>
<!-- Just copy everything. -->
<xsl:template match='@* | node()' mode='everything'>
<xsl:copy>
<xsl:apply-templates select='@* | node()' mode='everything'/>
</xsl:copy>
</xsl:template>
<!-- Copy everything but replace items with the replacement parameter. -->
<xsl:template match='@* | node()' mode='withreplacement'>
<xsl:param name='replacement' />
<xsl:copy>
<!-- Copy everything except item elements. -->
<xsl:apply-templates select='@* | node()[local-name() != "item"]' mode='withreplacement'>
<xsl:with-param name='replacement' select='$replacement' />
</xsl:apply-templates>
<!-- If this is where items are, apply the replacement node-set. -->
<xsl:if test='item'>
<xsl:apply-templates select='$replacement' mode='everything' />
</xsl:if>
</xsl:copy>
</xsl:template>
<!--
We matched the first of a slice of items.
Copy everything from the root, passing the current item
and its sibling(s) as the replacement.
-->
<xsl:template match='item' mode='firstofslice'>
<xsl:apply-templates select='/group' mode='withreplacement'>
<xsl:with-param
name='replacement'
select='. | following-sibling::item[position() < $itemcount]'
/>
</xsl:apply-templates>
</xsl:template>
<!-- Match to root, and put everything under a single element. -->
<xsl:template match='/'>
<root>
<!-- Grab every second item to create a new group. -->
<xsl:apply-templates select='group/item[position() mod $itemcount = 1]' mode='firstofslice' />
</root>
</xsl:template>
</xsl:stylesheet>
By the way, if you haven't already, check out the comments on the first post for a more efficient variation of the stylesheet.
Enjoy!
I spent a little bit of time with this the other day, and I thought I'd pass the learnings on, in hopes it helps someone.
This is the layout what I was trying to accomplish with WPF. In a section of my window, I wanted a bit of text at the top, and then the rest filled with items. The items in this case were bits of XML with an item template that created a nice representation, but for this post we'll just use buttons, which have the same effect.
My initial XAML looked like this. You can try pasting these into XAMLPad to follow along (and add more buttons or resize the window so all buttons won't fit in the view).
<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<StackPanel>
<ItemsControl>
<Button>Button</Button>
<Button>Button</Button>
<Button>Button</Button>
<!-- ... -->
</ItemsControl>
</StackPanel>
</Grid>
This is all well and good, but some of the Buttons are just clipped from the window and you can't get to them. This is because the ItemsControl doesn't have the built-in ability to scroll its contents, so I decided to go ahead an add a wrapping ScrollViewer.
<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<StackPanel>
<ScrollViewer>
<ItemsControl>
<Button>Button</Button>
<Button>Button</Button>
<Button>Button</Button>
<!-- ... -->
</ItemsControl>
</ScrollViewer>
</StackPanel>
</Grid>
This produces a very confusing situation, in which the scroll viewer is present, but the scroll bar is disabled and goes off the window.
After looking at this for a while, I realized that the problem is that the StackPanel doesn't constrain the size of its children. So if the scroll viewer wants to be huge so it doesn't have to, the StackPanel will arrange it so, even if it clips.
The solution then was to switch to something that did constrain its children. In particular, a DockPanel is great, as it will size the last child to occupy all remaining space.
<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<DockPanel>
<ScrollViewer>
<ItemsControl>
<Button>Button</Button>
<Button>Button</Button>
<Button>Button</Button>
<!-- ... -->
</ItemsControl>
</ScrollViewer>
</DockPanel>
</Grid>
Now I have a scroll viewer with an enabled scroll bar, which allows me to get to all the buttons.
Enjoy!
Aaron published an MSDN article on using Velocity that is very much worth checking out.
Some of the highlights:
- Why and how to scale your applications.
- Deployment and configuration of Velocity.
- Data analysis and cache design.
- ASP.NET Session integration.
One of the things I remember from DevConnections is how ridiculously popular it is to use this from ASP.NET, and how easy it is to improve the performance of your ASP.NET applications with the integrated support.
Enjoy!
This is something that I've been asked more than once, and so here goes an answer that might help if you run into this.
Let's say that you create a new project and borrow code or do something of the sort, and suddenly start getting an error message such as this one
xmllite.h(49) : error C2146: syntax error : missing ';' before identifier 'IXmlReader'
This typically points to a missing macro. You can fix this by adding this to your include headers:
#include "objbase.h"
If you're using Visual C++-style projects, this may already be included via stdafx.h including the Windows headers for you.
To continue on my previous example on slicing (I made the term up, by the way), today we'll do something a little different.
Let's say that instead of just inserting the slice elements and a few items, we want to copy the whole tree n times (where n is the number of slices), each time with a different slice of items. That includes elements beyond the things we're currently slicing.
So let's say we have this document, similar to the previous one.
<group groupattribute='1'>
<repeat-me>each time</repeat-me>
<item item='1'>1 <sub>text</sub> </item>
<item item='2'>2 <sub>text</sub> </item>
<item item='3'>3 <sub>text</sub> </item>
<item item='4'>4 <sub>text</sub> </item>
<item item='5'>5 <sub>text</sub> </item>
</group>
And we want to get this effect.
<root>
<group groupattribute="1">
<repeat-me>each time</repeat-me>
<item item="1">1 <sub>text</sub></item>
<item item="2">2 <sub>text</sub></item>
</group>
<group groupattribute="1">
<repeat-me>each time</repeat-me>
<item item="3">3 <sub>text</sub></item>
<item item="4">4 <sub>text</sub></item>
</group>
<group groupattribute="1">
<repeat-me>each time</repeat-me>
<item item="5">5 <sub>text</sub></item>
</group>
</root>
Here is a stylesheet that can accomplish this, using parameters to pass around the replacements nodes for each copy of the tree. As always, variations in the comments are welcome.
<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
<xsl:output method='xml' indent='yes'/>
<!-- Just copy everything. -->
<xsl:template match='@* | node()' mode='everything'>
<xsl:copy>
<xsl:apply-templates select='@* | node()' mode='everything'/>
</xsl:copy>
</xsl:template>
<!-- Copy everything but replace items with the replacement parameter. -->
<xsl:template match='@* | node()' mode='withreplacement'>
<xsl:param name='replacement' />
<xsl:copy>
<!-- Copy everything except item elements. -->
<xsl:apply-templates select='@* | node()[local-name() != "item"]' mode='withreplacement'>
<xsl:with-param name='replacement' select='$replacement' />
</xsl:apply-templates>
<!-- If this is where items are, apply the replacement node-set. -->
<xsl:if test='item'>
<xsl:apply-templates select='$replacement' mode='everything' />
</xsl:if>
</xsl:copy>
</xsl:template>
<!--
We matched the first of a slice of items.
Copy everything from the root, passing the current item
and its sibling(s) as the replacement.
-->
<xsl:template match='item' mode='firstofslice'>
<xsl:apply-templates select='/group' mode='withreplacement'>
<xsl:with-param
name='replacement'
select='. | following-sibling::item[1]'
/>
</xsl:apply-templates>
</xsl:template>
<!-- Match to root, and put everything under a single element. -->
<xsl:template match='/'>
<root>
<!-- Grab every second item to create a new group. -->
<xsl:apply-templates select='group/item[position() mod 2 = 1]' mode='firstofslice' />
</root>
</xsl:template>
</xsl:stylesheet>
Enjoy!
I'm very, very pleased about today's announcement on LINQ to XSD being available on CodePlex.
The functionality available should be esentially the same as what was released in the last Alpha Preview, so if you were already using this, it should be a smooth transition.
The community of developers interested in LINQ to XSD will now be able to include this in their applications, as it's being released under the Ms-PL license.
Enjoy!
First, let me start with a disclaimer: I'm not an XSLT guru. I know folks that can truly do amazing things with it. Every now and then, though, I can help someone, and I thought I'd share a solution I came up with recently. I'll be happy to see alternate solutions posted in the comments.
So, let's say you have an XML document such as this one:
<group>
<item>1</item>
<item>2</item>
<item>3</item>
<item>4</item>
<item>5</item>
</group>
You'd like to create "slices" of the items in the group, such that you get them reparented in twos (could be three, four or whatever - we'll go with two items per slice). Any remainder try to fill up as much as possible of the last slice, so the transformed document should look like this.
<group>
<slice>
<item>1</item>
<item>2</item>
</slice>
<slice>
<item>3</item>
<item>4</item>
</slice>
<slice>
<item>5</item>
</slice>
</group>
My solution has three templates: one for processing each item (I do some simple content copying "by hand"), one to process each slice (which has a the current context the first item in the slice), and one to process the whole document. The trick is to use the mod function to pick the beginning item of each slice, and to use the following-sibling axis to grab the ones that come right after.
Here's the XSLT for the solution that produces the desired result.
<xsl:stylesheet
version='1.0'
xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
<xsl:output method='xml' indent='yes'/>
<!-- Template for a single item in a slice. -->
<xsl:template match='item' mode='inslice'>
<item><xsl:value-of select='text()' /></item>
</xsl:template>
<!-- Template for each slice. -->
<xsl:template match='item' mode='firstofslice'>
<slice>
<xsl:apply-templates select='.' mode='inslice' />
<xsl:apply-templates select='following-sibling::item[1]' mode='inslice' />
<!--
"grow" the slice by adding more of these, but change the 'mod' below:
<xsl:apply-templates select='following-sibling::item[2]' mode='inslice' />
-->
</slice>
</xsl:template>
<xsl:template match='/'>
<group>
<!-- Grab every second item to create a slice. -->
<xsl:apply-templates select='group/item[position() mod 2 = 1]' mode='firstofslice' />
</group>
</xsl:template>
</xsl:stylesheet>
Enjoy!
One of my popular past entries is Working around invalid characters in XML. I don't know if folks actually search for this, but it's certainly something that I point them to when I want to help them understand the space a bit better.
If you've downloaded the Visual Studio Beta, you'll notice that the .NET Framework beta has a new method in XmlConvert (among a few others): IsXmlChar. This allows you to look at a character and decide whether it's valid or not. Some of the other new methods include checking for valid surrogate pairs or complete strings.
Enjoy!
I've posted a page on
XSLT Resources that I hope to add to over time - stay tuned.
Debugging is hard. There are many things we do to make it easier on ourselves.
- Feature-level things like building tracing and logging capabilities.
- Design-level things like having clear points at which state is checked for consistency (internal or parameters passed in, for example), so we narrow down the areas where things might have gone wrong.
- Code-level things like making sure that exceptions bubble up without losing the stack.
- Operational-level things like using tools to capture dumps on failure and monitoring performance counters, to have good data about the program and its environment.
John Robbins has a great post about build-time and environment-setup-time things you can do to make your debugging life easier, and PDB files are a big part of it. If you haven't debugged symbol-indexed and source-indexed programs in the past, you're in for a treat.
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
Enjoy!
Beth Massi shows off how you can use XML literals in VB.NET to do some very, very powerful stuff in a very, very straightforward way.
http://www.dnrtv.com/default.aspx?showNum=138
Enjoy!
Following up from my last post, danieldsmith asked about a couple of additional details. I think I responded in the comments, but because (a) it's generally useful, and (b) I had some problems with my network connection (because I monkeying around with it), the reply may have been lost. So here we go again.
First, is caching implemented for the resolved DTDs? No, the default resolver doesn't do any caching - files will always be requested. So if you're loading documents with DTDs in a tight loop, you might get a pretty significant perf improvement here.
Second, what happens if there is no network connectivity? Well, the framework can't do validation without the DTD, and even if it could it would be unable to expand entities, so as you might guess, the problem isn't silently ignored - you'll get an exception instead.
Trying this on my machine at home, I got two slightly different exception - your mileage may vary. The first time I had Fiddler running, and I got a System.Net.WebException with a Message value "The remote server returned an error: (502) Bad Gateway.", and a Status value of ProtocolError. There was a Response assigned to it, which had a message of its own, "Fiddler - DNS Lookup Failed".
Then I shut down Fiddler and got another WebException, although this time the message was "The remote name could not be resolved: 'www.w3.org'", and the Response of the exception was null.
So now you know. Keep an eye on your network activity, and turn off features that you don't use to get perf / stability improvements without having to go and make changes to your application.
As a side note, I like to run Fiddler every now and then, just to see what kind of web traffic my machine is generating - it's awfully interesting to see the kinds of things that are going on sometimes.
Enjoy!
