xsl-list
[Top] [All Lists]

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

2003-09-08 01:58:56


I need help writing an XSLT stylesheet to transform an HTML Help
contents
file (.hhc) into multiple Aurigma Deep Tree TOC .htm files
(http://www.aurigma.com/support/default.aspx?section=onlinehelp&mainsrc
=Hel>p
/DeepTree/Overview2.htm, with many thanks for Fedor Skvortsov for
making
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
Network
(MSDN) Library website
(http://www.msdn.microsoft.com/library/default.asp),
which loads only the root TOC nodes by default, and thereafter loads
TOC
nodes "on demand", when the user clicks an expandable node. As far as I
can
tell, by rummaging around the site's source files, clicking an
expandable
TOC node invokes an Internet Explorer-specific behavior (.htc) that
dynamically loads a TOC subtree, and inserts that subtree into the
existing
displayed TOC. (If you use a browser other than IE - such as Netscape -
then
the TOC is not quite as smart as this.) But I've never found the time
to
"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
this
email), which not only does most of what the MSDN Library website TOC
does,
but it's cross-browser compatible, too. (Unfortunately, unlike the MSDN
Library TOC, the Aurigma solution is frame-based, and doesn't highlight
the
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
file,
and the nodes in each subtree are defined in those files as JavaScript
array
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
contains
a subtree of child nodes) looks like this:

oNodes[1] = new node("Services", null , "folder", "main",
"TOC/Services.htm");
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
devices.

First, I'd planned to use the W3C Tidy tool to convert the .hhc into
XHTML,
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,
and
save them as a TOC/something_or_other.htm file, starting with
TOC/Root.htm
(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!
(In
particular, it would be nice to have TOC syncing, and not to use
frames...)

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">
hi</subitem></subitem>
<subitem id="myitem2">by</subitem>
</item>

then we could pass in a parameter called started.

<xsl:param name="startid"/>

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

</xsl:template>

<xsl:template match="subitem[not(subitem)]">
<li><xsl:apply-templates/></li>
</xsl:template>

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

</li>
</xsl:template>

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

<ul>
<li>
<ul><li>hi</li></ul>
</li>
</ul>

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:  http://www.mulberrytech.com/xsl/xsl-list



<Prev in Thread] Current Thread [Next in Thread>