Suggestions - to give more power to this report

[hidegh]

Try to allow any XHTML to be converted/parsed.
There are free tools that makes from a HTML XHTML.

What you should (could) do:

1. Remove the check if it's your type of report:

@* Generator: Template *@

<!ENTITY ldquo "&#8220;">
<!ENTITY lsquo "&#8216;">
<!ENTITY rdquo "&#8221;">
<!ENTITY rsquo "&#8217;">
<!ENTITY quot "&#34;">

]>

2. Except /report/content/pageSequence your reports are a normal XHTML documents. The most important XHTML tags are already transformed by the supported XSLT.

So if you modify the structure a bit, it could be a HTML to XHTML to PDF/CSV converter.

3. Don't fully understand why you need to generate templates into CS. Razor can do this on the fly, precompiled code can be cached (f.e. static variable inside class)...

4. Examples are cool, documentation would be even better.

[becdetat]

Awesome suggestions, thanks (and thanks for your email as well). I'll see what I can do when I have some free time. Meanwhile, please feel free to submit PRs if you want. Cheers :-)

[becdetat]

Ok, I remember why it converts to CS. I didn't want a compile step to be part of the runtime story. This library is used by several rich client applications (WinForms and WPF). Runtime compilation of the reports has two problems in those scenarios:

• Long lead time on startup
• Need to bundle the source files with the system, adding to deployment complexity and giving end-users access to the runtime (potential security hole)

Situations where this isn't an issue - ie websites - you can just use a Razor view to generate the markup for the report directly, and cache it if needed. Note that you don't need to use Razor to use Crispin, you can just push the xrpt format straight in. I use RazorGenerator for the example application and library, and to generate a report DLL for the commercial applications that use Crispin.

[becdetat]

Re points one and two, it would probably be easier to add a preliminary step to convert a HTML document to something supported, ie wrap it in the required /report/content/pageSequence tags and do other changes. I'll see what I can put together but it is likely to be fairly buggy but interesting. One of the big sticking points is CSS support (or lack thereof) which is why there are a heap of custom tags around styling the resulting XSL-FO.