forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: [CONTRIB] auto generation of menus
Date Wed, 08 Oct 2003 11:12:39 GMT
On Tue, Oct 07, 2003 at 02:59:54AM +0200, Eric BURGHARD wrote:
> Le Lundi 06 Octobre 2003 08:47, Jeff Turner a écrit :
> > On Fri, Oct 03, 2003 at 11:12:04PM +0200, Eric BURGHARD wrote:
> > > Hi,
> > >
> > > I've made some modifications to directory2book.xsl (which generate side
> > > menu based on directory content):
> > > -little cleanup (expected-extension argument no more needed)
> > > -kind of control on which items are present or not
> > > -allow parametrable sorting of menu-items
> > > -easily extensible.
> >
> > Nice.  I've committed it with some modifications:
> >
> >  - Used the existing pathutils.xsl instead of substring-last.xsl
> >  - I didn't understand the purpose of documentdirectory.xsl, so I put its
> >    enhanced get-label template in directory2book.xml.  Any reason to
> >    separate it out, other than to demonstrate its 'overridability'?
> >
> ;-)
> 
> Yeah, in fact, directory2book.xsl is not specificly designed to be used with 
> XPathDirectoryGenerator. Right ? After a simple DirectoryGenerator you've got 
> no dir:xpath nodeset in the result. So is there any good reason to compute 
> the menu-items labels from inexistants tags and rely on the default behavior 
> which take them from the filenames ?

True.

Is there any reason we shouldn't just insist on the use of
XPathDirectoryGenerator?  Why bother maintaining a subset of
functionality for DirectoryGenerator?  Having labels equal to the
filename (minus extension) sounds very unappealing to me.

> On the other side, when you apply documentdirectory2book.xsl you say 
> indirectly your intention to scan directory full of document-v20 compliant 
> xml. This stylesheet rely on XPathDirectoryGenerator because the get-label 
> template make use of dir:xpath contents.
> 
> If you've got docbook directories, perhaps you want to get the labels from 
> something else than <meta name="short-title"/> (the meta tag could possibly 
> not exists in docbook or exists in another branch than document/header, i 
> don't know). So just edit a new docbookdirectory2book.xsl which only need to 
> override the get-label with something like:
> 
> <xsl:template name="get-label">
>  <xsl:value-of select="dir:xpath/whatever-tab"/>
> </xsl:template>
> 
> and modify your sitemap.xmap accordingly
> 
> <map:generate label="debug" src="content/xdocs/{1}{2}" type="xpathdirectory">
>   <map:parameter name="xpath" value="//whatever-tab">
>   </map:generate>
>   <map:transform src="resources/stylesheets/docbookdirectory2book.xsl"/>
>   <map:serialize type="xml">
> </map:generate>
> 
> In the last version of my directory2book.xsl (attached)

.. merged with that in CVS.

> I also define a 
> get-href named template. That way you can easily compute the urls served by 
> menu-items. Example: for my simple gallery i use a jpegdirectory2book.xsl 
> which is quite simple and clear:
> 
>     <xsl:import href="directory2book.xsl"/>
>     <xsl:output doctype-public="-//APACHE//DTD Cocoon Documentation Book 
> V1.0//EN" doctype-system="book-cocoon-v10.dtd"/>
> 
>     <!-- link to screen oriented jpegs -->
>     <xsl:template name="get-href">
>         <xsl:param name="corename"/>
>         <xsl:value-of select="concat($corename, '-1024.jpg')"/>
>     </xsl:template>
> 
> </xsl:stylesheet>
> 
> for each of my jpegs i've got a menu-item item which link to something like 
> img-1024.jpg which refer to img.jpg with a 1024 pixels height.
> 
> Somewhere in my sitemap.xmap i've got this to generate jpeg at a given height.
> 
> <map:match pattern="(.*)-([0-9]*).jpg" type="regexp">
>   <map:read src="content/xdocs/{1}.jpg" type="image">
>      <map:parameter name="height" value="{2}"/>
>   </map:read>
> </map:match>

Cool!

...
> > Then pages could have some metadata used by the sorting algorithm:
> >
> > <meta name="group">GettingStarted</meta>
> >
> > <meta name="comes-after">index.html</meta>
> >
> > <meta name="comes-before">primer.html</meta>
> >
> 
> Yeah ! much more flexibility like this ! Thus you can already achieve quite 
> the same behavior with the actual sorting mechanism and without the hassle of 
> programming a constraints resolution engine. Use directory hierachie a 
> relaxed numbering scheme (like sysV init filenames):
> 
> directory: GettingStarted
> file1
> <meta name="menu-order">S5</meta>
> 
> index.xml
> <meta name="menu-order">S0</meta>
> 
> primer.xml
> <meta name="menu-order">S20</meta>
> 
> and do your sorting with
> 
> <map:transform src="resources/stylesheets/documentdirectory2book.xsl">
>    <map:parameter name="sort-select" 
> value="dir:xpath/meta[@name='menu-order']"/>
> </map:transform>

That almost works currently, except the sort is lexical not numeric so
S10 < S2.

> PS: What did the pathutils.xsl do in resources/skins/common/xslt/html 
> directory ? Shouldn't it be placed in resources/stylesheets ?

It originated from the common need in skin XSLTs.  Since its generic it
makes a bit more sense in resources/stylesheets, but moving it would
likely break custom skins which expect it in its existing location.


--Jeff


Mime
View raw message