forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: draft howto dtd
Date Mon, 27 May 2002 19:07:33 GMT
Hi Ivelin,

Ivelin Ivanov wrote:

>Good points.
>
>----- Original Message -----
>From: "Robert Koberg" <rob@koberg.com>
>  
>
>>Hi,
>>
>>On the book.xml (menu/site-structure) and index.xml (content piece), for
>>example: why duplicate link's href values - if you had access to
>>book.xml (the menu or site structure) you could reference links by ID
>>instead of a hard coded link. For example the content hard codes links
>>to faq.html or http://xml.apache.org/cocoon. Why not have these in one
>>location (book.xml) and refer to them? It would be nice to reuse the
>>data provided by book.xml (perhaps even store more page level meta info
>>there?? show-toc, show-meta-data, show-on-nav - or at the folder level:
>>number-pages, show-on-nav - etc). Even better have book.xml be a
>>representation of the entire site hierarchy. Then you can recursviely
>>build paths to documents. For all the good book.xml does it could be
>>written straight into the XSLT (and included :).
>>    
>>
>
>Can you suggest a concrete (preferably standard) technique for documents to
>use links from within book.xml?
>
Sure. How about something like this:

book.xml (I have an alternative if you are interested...)
-----------------------------
<book>
   <menu id="f1234" label="Document Sample" folder-name="samples">
      <menu-item id="c3432" label="Samples Home" file-name="index.html"/>
      <menu id="f6234" label="Pipelines" folder-name="pipelines">
         <menu-item id="c7663" label="Pipeline 1" 
file-name="pipeline1.html"/>
         <menu-item id="c8795" label="Pipeline 
2" file-name="pipeline2.html"/>
      </menu>
   </menu>
</book>

a content XML, say the cocoon home page:
-----------------------------
<article>
  <title>jdfghjdfgh jsdfjksd</title>
  <para>Check out <link id="c8795">Pipeline 2</link> or go out to 
bubba's site to see this <link 
out="http://www.bubba.com/example.html">example</link>
</article>

<!-- perhaps all you need is <link id="c8795"/>  and the label or link 
text can come from the book.xml, see the XSLT below for clues how this 
could be done -->

============================
If you can pass the XML (nodeset) in as a param then you would not need 
the XPath document function. In a primary XSLT you bring the top-level 
param for the above config XML:
---------
<xsl:param name="book-xml"/>
=======
also make a key at the top-level for speed in accessing the correct 
menu{-item}:
-------
<xsl:key name="menu-id-key" match="menu | menu-item" use="@id"/>
========
Then at some point you match a link:
-------
<xsl:template match="link">
<!-- choose whether it is internal or external -->
   <xsl:variable name="href">
       <xsl:choose>
         <xsl:when test="boolean(@id)">
            <xsl:apply-templates select="$book-xml">
               <xsl:with-param name="link_id" select="@id"/>
            </xsl:apply-templates>
         </xsl:when>
         <xsl:when test="boolean(@out)">
            <xsl:value-of select="@out"/>
         </xsl:when>
      </xsl:choose>
   </xsl:variable>

   <a href="{$href}">
      <xsl:if test="boolean(@out)">
         <xsl:attribute name="target">_blank</xsl:attribute>
      </xsl:if>
      <xsl:apply-templates/>
   </a>
</xsl:template>

<!-- change contexts to the book-xml nodeset (so you can use the key and 
travel the XML) -->
<xsl:template match="book">
   <xsl:param name="link_id"/>
   <xsl:apply-templates select="key('menu-id-key', $link_id)" 
mode="linker"/>
</xsl:template>

<!-- recurse over the path to the document and provide the path info -->
<!-- something like this - not tested -->
<xsl:template match="menu-item | menu" mode="linker">
   <xsl:apply-templates select="parent::menu"/>
   <xsl:text>/<xsl:text>
   <xsl:value-of select="@file-name"/>
</xsl:template>

<xsl:template match="menu-item | menu">
   <xsl:apply-templates select="parent::menu"/>
   <xsl:text>/<xsl:text>
   <xsl:value-of select="@folder-name"/>
</xsl:template>





>It has been proposed that W3C Topic Maps can be useful.
>http://www.gca.org/papers/xmleurope2000/papers/s11-02.html
>
have not looked too far into this :(

>
>How about using the document link tag like this:
>
><link href="document({$bookDocument})/menu/menu-item[@id='howto-step1'">
>
See above

>
>Where the bookDocument variable is passed in from the sitemap.
>This will require that the document files are not plain xml files, but xslt
>files instead.
>
hmmm... why do they need to be XSLT? Can it be passed in as a nodeset to 
a top-level param, since we can't use the XPath document function to get 
it from the filesystem.

best,
-Rob

>To keep things clean maybe the <link/> tag can be extended with syntax like:
>
><link href="book/howto-step1"/> or similar
>
>  
>
>>I still don't see what is wrong with using import or include to bring
>>together many XSLTs into one. The cocoon way of performing multiple
>>transformations seems like way too much work when you want to break your
>>XSLT into component pieces for easy reusability.
>>
>>I think you miss a *great deal* of the benefit of XSLT by not using the
>>document function and import/include. I can't seem to come up with a
>>good way to do the things I want to do without them.
>>    
>>
>
>I agree that the map:aggregate in the sitemap is somewhat redundand.
>What are its advantages over passing the components as parameters to a
>normal XSLT page
>which includes them either through include/import or the document()
>function.
>The advantages that I see in the latter approach are that its utilizing XML
>standards.
>It also allows use of namespaces in the aggregating document, allows
>references to validation documents,
>and everything else you can use in an XSLT document.
>Additionally the link referencing suggested above is natural.
>
>
>Cheers,
>
>Ivelin
>
>
>  
>
>>I would love clear, explicit documentation on how to do things that are
>>commonplace in regular XSLT but are to be avoided when using cocoon.
>>
>>best,
>>-Rob
>>
>>
>>    
>>



Mime
View raw message