RE: [xsl] Transforming HTML Help contents (.hhc) file into Aurigma Deep Tree TOC .htm files

Subject: RE: [xsl] Transforming HTML Help contents (.hhc) file into Aurigma Deep Tree TOC .htm files
From: "bryan" <bry@xxxxxxxxxx>
Date: Mon, 8 Sep 2003 10:58:56 +0200

>I need help writing an XSLT stylesheet to transform an HTML Help
>file (.hhc) into multiple Aurigma Deep Tree TOC .htm files
>/DeepTree/Overview2.htm, with many thanks for Fedor Skvortsov for
>this code available... see the copyright notice in the "P.S." at the
end of
>this email).
Well I have some comments on this, although I can't really focus right
now on actual implementation. 

>For nearly two years, I've wanted to emulate the Microsoft Developer
>(MSDN) Library website
>which loads only the root TOC nodes by default, and thereafter loads
>nodes "on demand", when the user clicks an expandable node. As far as I
>tell, by rummaging around the site's source files, clicking an
>TOC node invokes an Internet Explorer-specific behavior (.htc) that
>dynamically loads a TOC subtree, and inserts that subtree into the
>displayed TOC. (If you use a browser other than IE - such as Netscape -
>the TOC is not quite as smart as this.) But I've never found the time
>"re-engineer" this.

I seem to remember an extreme xml column where they re-engineered the
TOC to be loaded via c#, the reason being that an earlier version used
either wd-xsl or xslt, the argument was that there was significant gains
made by using c#. Don't much care for cross language comparisons like
that though.

>Today, I stumbled across Aurigma Deep Tree (see the link at the top of
>email), which not only does most of what the MSDN Library website TOC
>but it's cross-browser compatible, too. (Unfortunately, unlike the MSDN
>Library TOC, the Aurigma solution is frame-based, and doesn't highlight
>current topic in the TOC, or synchronize the TOC with the topic.)

problems, uses iframes. Thus is not really cross-browser, it is only
cross-most browsers compatible. 

>With Aurigma Deep Tree, each TOC subtree is defined in a separate HTML
>and the nodes in each subtree are defined in those files as JavaScript
>elements. The Aurigma website describes all this in detail, but I'll
give a
>couple of examples here. A "folder" TOC node (that is, a node that
>a subtree of child nodes) looks like this:

>oNodes[1] = new node("Services", null , "folder", "main",
this I have some experience with, first off can you reverse engineer the
javascript well enough that you know what's going on with the whole
thing. Sometimes it can be a real challenge to go back through someone
elses spaghetti and extracting the sauce. Anyway there's one thing that
has caused me to go off of this kind of dynamic TOC, search engines
don't index TOC contents, and most often the script requires a call to
be made inside the body where you want the script to start writing,
which can lead to further problems in various xhtml presentation

>First, I'd planned to use the W3C Tidy tool to convert the .hhc into
>so that it can be transformed by an XSLT stylesheet.

With the newer help files available with .Net technologies, and I'm
supposing with Windows 2003 help files, and their TOC may be in an xml
format already.

>Then I'd write an XSLT template that would, say, iterate (for-each)
over >the
><li> elements inside an <ul>, build the necessary oNode[x] assignments,
>save them as a TOC/something_or_other.htm file, starting with
>(as required by the default Aurigma JavaScript).
So I suppose you're using a processor with an extension function
allowing multiple outputs.

>Of course, if someone already has a better method than Aurigma Deep
Tree >for
>displaying massive TOCs on the Web, then I'd like to hear from them!
>particular, it would be nice to have TOC syncing, and not to use

the difficulty of something using xslt is dependent on the input formats
suitability for the task, as well as its suitability for being handled
via xslt. 

Let us suppose we had a structure like this:

<item id="myitem">
<subitem id="myitem1">
<subitem id="myitem11">
<subitem id="myitem2">by</subitem>

then we could pass in a parameter called started.

<xsl:param name="startid"/>

<xsl:template match="item">
<xsl:apply-templates select="subitem[starts-with($startid,@id)]"/>


<xsl:template match="subitem[not(subitem)]">

<xsl:template match="subitem[subitem]">
<xsl:apply-templates select="subitem[starts-with($startid,@id)]"/>


which if you pass in the parameter started with a value myitem11 should


note that this isn't a particularly good example but it does indicate a
possible method whereby with a linking structure one can keep passing
back to the server requests for a deeper nesting in the hierarchy. 

Another problem, not sure if I remember correctly, but I think nested
lists might be deprecated. 

 XSL-List info and archive:

Current Thread