From XSLT to SSRS, and most probably back again some day

Turns out that Zach remembers me…

He’s brought me a really nice little SSRS problem that highlights some of the limitations of HTML Placeholders.  While I was happy to extoll the virtues of HTML Placeholders, as a new-ish member of the RDL family of features, they can’t do everything for you.  They support only a subset of HTML tags.

Microsoft/MSDN is not coy about what is, and is not, supported from the HTML standard(s).  I think that the pattern is clear, and the limitations are sound, once you think about what the engine is trying to do itself, plus what instructions it can reasonably pass on to the different renderers.

So, I want to point this out, for those of you who are going down the HTML Placeholder path: read the MSDN post I’ve just linked to. Have reasonable expectations, and manage the expectations of your users.

When Zach comes out of whater turkey-induced stupor he’s currently in, and reviews my proposed solution for his requirement, I’ll write about it here.  This is really another case of “you pays your money and you takes your choice”.  HTML Placeholders can do some of what you need, with relatively little pain, for most of the rest of your needs there is always code. 

For a very, very small percentage of high-end requirements there are still custom report items — although I still haven’t needed to “go there” in the 2008 RDL schema.  When you get to the point where you need something like this, you have to start asking yourself while you’re using an RDL in the first place.  You’re saying to the RDL: accept this blob.  Don’t try to integrate it with the content you’re controlling. 

A specialized graph type seems like an appropriate candidate for this treatment, because you can dedicate a region of the page layout for the RDL and say “render this image… .here”.  No different from any JPG.

But, IMHO, an RTF control is less suitable. Although I’ve no doubt that some such control has already been created by third parties — here is a typical thread addressing the idea — it’s an inherently limited concept.  RTF wants to do page layout, and it’s going to butt up against the RDL’s need to control the flow, paginate, etc (or, more exactly, provide proper information for the various renderers to do the same thing).  You basically have two options:

• 1 – Treat the RTF like a graph or an image/blob.  It gets so much space, exactly, in the layout.  Any overflow is cut off, optionally with an ellipsis or similar.  This is acceptable if you can control your RTF content and know that you have only short entries.  It tends not to render as crisply as the rest of your report, unfortunately, but it is doable.
    
• 2 – Treat the RTF like a parseable element, allowing the engine to re-flow it and making it available for pagination in different renditions as needed.  Because RTF is complex, this option turns into a “strip-RTF”, or RTF-to-Text, option.  It is hardly rich text any more, but it does allow you to make use of critical content that happens to be stored in your databases as RTF  and of unknown length.

The HTML Placeholder feature strategy is a modification of option #2.  Because HTML is somewhat less complex than RTF, it can be incorporated as real text, rather than a blog, with a modified stripping algorithm.  The compromise removes page layout capabilities from HTML but retains some of the rich formatting capabilities of the original.  This is the pattern of tag omission and inclusion, to which I alluded earlier and which is clearly evident in the official MSDN description of the feature.

I’ll go on to discuss Zach’s question, involving a requirement that is both genuinely universal and yet probably impossible to fulfill within the above restrictions, in a followup post, but I wanted to post these fundamentals first. 

Why is elaborating on HTML Placeholders, or thinking about when to use custom controls, fundamental, in my view?

Because.

You’re learning a basic approach to winning over the RDL.

The idea is to “think like the SSRS designers”, and by “designers” I mean the human developer authors of the tools, not the Visual Studio design surface, and to understand the problems they’re trying to solve.  Then look at the problem Zach (or you) need to solve, and imagine what the designers might do if they had unlimited budget and no needs to satisfy except your one requirement. 

Think about it concretely and realistically. What would be the exactly-right approach?  Chances are the tools that you have, in a little custom code, are really no different from what the designers would have to do internally. 

There is no magic to what happens internally.  Make it happen externally.  Sure it will run a little slower, but it will run. 

And, here’s an extra reason why: if you do it generically enough to solve other people’s problems, you’re giving the designers what they need to pseudo-code a more performant version for the next release.  You’re nailing the requirement, the behavior that is truly useful.  This is more than half the battle but it is often extremely difficult to accomplish without your trail-blazing.

If you are Eager enough

I just said there is no magic to internal behavior in the report engine. There is, however, sometimes Half-Magic.

I have previously thought and publicly said, as recently as two months ago, that you can’t adjust the style XML that shows up in the New Report Wizard,

I now know that this ain’t strictly so; see  this post for an overview of what to do. 

I’ve been experimenting with adjusting StyleTemplates.xml with mixed results, for completely practical reasons: in our school district we have many people writing reports, and I’ve been charged with branding the report authorship process, not just the Report Manager interface. 

In the past, I’ve accomplished this with a little more code than would be appropriate for non-developer report authors, so I do want to give the Wizard customization a full chance.  There have been a number of stoppers, so far, in doing everything as seamlessly as one would like.

I will continue this research and present my full results as soon as I can. 

Meanwhile, there is something of a “dark side” here, a reversal of what I’ve said above about our ability to write equivalent code to the internal code to solve Zach’s problem when HTML Placeholders are not good enough: For branding, we really don’t have the same capabilities as the internal code.  And we immediately see real limitations when that happens.

Specifically, we don’t have a custom code hook for what goes on when you invoke this snappy little item, shown here in Report Builder 2.0 new report: 

 

If we did, if (for example) we could attach this kind of instructions to the template Report.RDL…

Now you’re talking really fun branding opportunities for our non-developer report authors.  I’d burn a little incense to the designer-gods for that.