[Mono-docs-list] XSLT Merge

[Jonathan Pryor]

On Tue, 2008-03-11 at 15:42 -0400, Jonathan Pryor wrote:
> Up next I plan on making monodoc/engine/mono-ecma-impl.xsl more like
> monodoc/tools/stylesheet.xsl, in particular generating CREF-style
> hyperlinks instead of...whatever you want to call the current output.
> This will change links such as:
> 
> 	/docs/monodoc.ashx?link=M:System.Array.AsReadOnly<T>(T[])
> 
> into
> 
> 	/docs/monodoc.ashx?link=M:System.Array.AsReadOnly``1(``0[])
> 
> This will permit two things:
> 
> 1. ecma-provider will have a consistent URL that it needs to parse
> (currently it needs to cope with both to some broken extent, and
> completely ignores the former, which is why half the links to generic
> methods on go-mono.com/docs never work); and
> 
> 2. improve integration with monodocs2html, as it currently generates the
> latter-style links to System.* types, so this will continue to work in a
> better supported fashion.

This has just been committed as well.

Consequently monodoc/tools/stylesheet.xsl is *much* smaller, as it
shares a majority of its code with monodoc/engine/mdoc-html-utils.xsl
now.  Even better:

  - CSS output now generates the JavaScript "bling" discussed here:
	http://www.jprl.com/Blog/archive/development/2008/Feb-19.html
  - Navigation involving generic types actually works a majority of the 
    time now, instead of randomly.

The biggest fix is that it actually works now; the previous fix
refactored monodoc/engine/mono-ecma.xsl etc., but placed all dependent
XSLT files into resources within the monodoc.dll assembly.  It did NOT,
however, allow the XslTransform class to *use* the embedded resources;
consequently, it would work if your CWD was monodoc/engine, and would
fail if the CWD was anything else.  Oops.

Any testing would be appreciated.

Thanks,
 - Jon