You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Litrik De Roy <co...@litrik.com> on 2002/09/15 15:07:27 UTC
About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Michael,
I don't know about the book.xml you mention but, I'll try to explain what I
do..... ("Real programmers don't comment their code. If it was hard to
write, it should be hard to understand.")
All XSP pages have an attribute "uri" on my top element "Page". It
identifies the page within the whole site and its the value is also what
will guide the sitemap.xmap to this XSP. (I know... "uri" might not be the
best name for the attribute but that's what it is called...)
For example scriptura.xsp contains:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
<?xml version="1.0"?>
<xsp:page
language="java"
xmlns:xsp="http://apache.org/xsp"
>
<Page uri="/products/scriptura.html">
<Main>
...
</Main>
<Extra>
...
</Extra>
</Page>
</xsp:page>
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
This is what the sitetree.xml looks like:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
<?xml version="1.0"?>
<Site uri="/welcome.html" title="Welcome" navbar="yes">
<Page uri="/company.html" title="Company" navbar="yes">
...
</Page>
<Page uri="/products.html" title="Products" navbar="yes">
<Page uri="/products/dtm.html" title="DTM for AS/400e Servers"
navbar="yes">
...
</Page>
<Page uri="/products/scriptura.html" title="Scriptura" navbar="yes">
<Page uri="/products/scriptura/overview.html" title="Overview"
navbar="yes">
<Page uri="/products/scriptura/overview/designer.html" title="Scriptura
Designer"/>
<Page uri="/products/scriptura/overview/engine.html" title="Scriptura
Engine"/>
</Page>
...
</Page>
...
</Page>
...
<Page uri="/error404.html" title="Page not found" sitemap="no"/>
<Page uri="/site/error-dl.html" title="Download Error" sitemap="no"/>
</Site>
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
The "Site" contains nested "Page"s. Each "Page" has a "uri" that will be use
to map against what is in the XSP, a "title", and possibly a navbar="yes" to
indicate that this page should appear in the navigation bar, and possibly a
sitemap="no" to indicate that this page should not appear in the sitemap.
Here is a stripped down version of the stylesheet that converts my own XML
to real HTML. Look at the following:
- sitetree.xml gets included using the XSL document() function
- variable "thispage" contains the uri of this page
- variable "navbarpage" contains the uri of the youngest ancestor with a
navbar attribute (this way pages with no navbar attribuet will be
represented in the navigation bar by its parent or grandparent or....)
- <title> shows how sitetree.xml is used to construct a title containg the
parents of the page
- the template "Navbar" constructs the navigation bar using the 5 XPath axis
: ancestor, preceding-sibling, self, child, following-sibling
- the template "NavbarItem" generates the HTML for an item in the navigation
bar using the parameter "relation" to know whether it should generate a link
or just text
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output indent="no" method="html"/>
<xsl:variable name="SiteTreeFile"
select="document('../metadata/sitetree.xml')"/>
<xsl:template match="Page">
<xsl:variable name="thispage">
<xsl:value-of select="@uri"/>
</xsl:variable>
<xsl:variable name="navbarpage">
<xsl:value-of
select="$SiteTreeFile//*[@uri=$thispage]/ancestor-or-self::*[@navbar][1]/@ur
i"/>
</xsl:variable>
<html>
<head>
<title>Inventive Designers
<xsl:for-each
select="$SiteTreeFile//Page[@uri=$navbarpage]/ancestor-or-self::Page">
- <xsl:value-of select="@title"/>
</xsl:for-each>
</title>
...
<tr valign="top">
<td>
<table width="100%" cellspacing="0" cellpadding="0">
<tr>
<xsl:call-template name="Navbar">
<xsl:with-param name="navbarpage"><xsl:value-of
select="$navbarpage"/></xsl:with-param>
</xsl:call-template>
<xsl:apply-templates select="Main"/>
<xsl:apply-templates select="Extra"/>
</tr>
</table>
</td>
</tr>
...
</body>
</html>
</xsl:template>
<xsl:template name="Navbar">
<xsl:param name="navbarpage"/>
<td class="Navbar">
<p>
<xsl:for-each
select="$SiteTreeFile//*[@uri=$navbarpage]/ancestor::*[@navbar]">
<xsl:call-template name="NavbarItem">
<xsl:with-param name="relation">ancestor</xsl:with-param>
</xsl:call-template>
</xsl:for-each>
<xsl:for-each
select="$SiteTreeFile//*[@uri=$navbarpage]/preceding-sibling::Page[@navbar]"
>
<xsl:call-template name="NavbarItem">
<xsl:with-param name="relation">sibling</xsl:with-param>
</xsl:call-template>
</xsl:for-each>
<xsl:for-each select="$SiteTreeFile//*[@uri=$navbarpage]">
<xsl:call-template name="NavbarItem">
<xsl:with-param name="relation">current</xsl:with-param>
</xsl:call-template>
</xsl:for-each>
<xsl:for-each
select="$SiteTreeFile//*[@uri=$navbarpage]/child::Page[@navbar]">
<xsl:call-template name="NavbarItem">
<xsl:with-param name="relation">child</xsl:with-param>
</xsl:call-template>
</xsl:for-each>
<xsl:for-each
select="$SiteTreeFile//*[@uri=$navbarpage]/following-sibling::Page[@navbar]"
>
<xsl:call-template name="NavbarItem">
<xsl:with-param name="relation">sibling</xsl:with-param>
</xsl:call-template>
</xsl:for-each>
</p>
</td>
</xsl:template>
<xsl:template name="NavbarItem">
<xsl:param name="relation"/>
<xsl:choose>
<xsl:when test="$relation='current'">
<xsl:element name="p">
<xsl:attribute name="class">NavbarItem</xsl:attribute>
<xsl:attribute name="style">font-weight: bold ; margin-left:
<xsl:value-of select="count(ancestor::*)"/>em ;</xsl:attribute>
<xsl:element name="a">
<xsl:attribute name="class">NavbarLink</xsl:attribute>
<xsl:attribute name="href"><xsl:value-of
select="@uri"/></xsl:attribute>
<xsl:value-of select="@title"/>
</xsl:element>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:element name="p">
<xsl:attribute name="style">margin-left: <xsl:value-of
select="count(ancestor::*)"/>em;</xsl:attribute>
<xsl:attribute name="class">NavbarItem</xsl:attribute>
<xsl:element name="a">
<xsl:attribute name="class">NavbarLink</xsl:attribute>
<xsl:attribute name="href"><xsl:value-of
select="@uri"/></xsl:attribute>
<xsl:value-of select="@title"/>
</xsl:element>
</xsl:element>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
And finally the same stylesheet also contains the code to generate the
sitemap page:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
<xsl:template match="Sitemap">
<xsl:variable name="no">no</xsl:variable>
<xsl:for-each select="$SiteTreeFile//*[not(@sitemap) or @sitemap!=$no]">
<xsl:call-template name="SitemapItem">
</xsl:call-template>
</xsl:for-each>
</xsl:template>
<xsl:template name="SitemapItem">
<xsl:element name="p">
<xsl:attribute name="style">margin-left: <xsl:value-of
select="count(ancestor::*) * 2"/>em;</xsl:attribute>
<xsl:attribute name="class">SitemapItem</xsl:attribute>
<xsl:element name="a">
<xsl:attribute name="href"><xsl:value-of select="@uri"/></xsl:attribute>
<xsl:value-of select="@title"/>
</xsl:element>
</xsl:element>
</xsl:template>
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
Litrik De Roy
www.litrik.com
----- Original Message -----
From: "Michael Wechner" <mi...@wyona.org>
To: <co...@xml.apache.org>
Sent: Sunday, September 15, 2002 1:26 PM
Subject: Re: Link Livesites: Inventive Designers
>
>
> Litrik De Roy wrote:
>
> > Inventive Designers (http://www.inventivedesigners.com/) is a belgian
> <snip/>
> > - A special sitetree.xml document and some complex XPath expressions for
> > generating the navigation bar on each page, and the sitemap page.
>
>
>
> Is it possible to take a look at your sitetree.xml? Is there any
> relationship to the book.xml?
>
> Thanks
>
> Michael
>
>
>
>
>
>
> > - Lotus Domino for iSeries(AS/400) as the backend database for all FAQs,
> > Events, Press Quotes. Access is done through the "Lotus Domino Toolkit
for
> > Java/CORBA".
> > - iSeries(AS/400) for execution of some existing code. Access is done
> > through the "IBM iSeries Toolbox for Java"
> >
> >
> > Litrik De Roy
> > www.litrik.com
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
> >
> > To unsubscribe, e-mail: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
> >
>
>
> --
> OSCOM - Open Source Content Management Conference
> September 25th - 27th 2002, Berkeley, California
> http://www.oscom.org/conferences/berkeley2002/
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Litrik De Roy <co...@litrik.com>.
----- Original Message -----
From: "Michael Wechner" <mi...@wyona.org>
To: <co...@xml.apache.org>
Sent: Sunday, September 15, 2002 4:07 PM
Subject: Re: About sitetrees and navigation bars (long post) (Was: Re: Link
Livesites: Inventive Designers)
> Dear Litrik
>
> Thanks a lot for your detailed explanation.
You're welcome. It was a slow sunday ;o)
>
> I think "book.xml" is used by the Forrest project
> (http://xml.apache.org/forrest) to generate their navigation and sitemap,
> but I am not sure, because I never found the time to check for myself.
I'm already glad I was able to master Cocoon. One Open Source project at a
time is more than enough for me :o)
>
> There are so many solutions out there with regard to the generation
> of navigation, bread-crumb-path and (web-)sitemap.
I have designed my solution based on some experience I had with a static web
site generated from XML where I did not have a sitetree.xml with the
metadata about the site's structure. That was/is a big maintenance hassle.
<snip>
> An even more important issue is scalability (and related to it
> performance) and maintenance of the sitetree.xml or whatever one wants
> to call it.
>
> Did you ever try out your approach with more pages envolved, let's say
> 1000 or even a 1000000?
Nope.
Scalability is not an issue for me. My company would need to develop a lot
more products to get to 1000 pages. Currently the sitetree.xml has approx 50
pages.
>
> Thanks
>
> Michael
>
>
Litrik De Roy
www.litrik.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Michael Wechner [mailto:michael.wechner@wyona.org]
> Sent: Sunday, September 15, 2002 7:51 AM
> Robert Koberg wrote:
>
> > Hi Michael,
> >
> >
> <snip/>
> >>
> >>An even more important issue is scalability (and related to it
> >>performance) and maintenance of the sitetree.xml or whatever one wants
> >>to call it.
> >>
> >>Did you ever try out your approach with more pages envolved, let's say
> >>1000 or even a 1000000?
> >>
> >
> > My approach would not work well with sites this large. But for 80%
> (?) of the
> > sites out there it would work well.
>
>
> It would be interesting to know the average size (number of pages),
> resp. distribution of websites out there.
>
> There's certainly no need to "break a butterfly on a wheel" (why do you
> say that in english? In german you say "to shoot with cannons on sparrows")
Haven't heard that one. I usually say 'trying to kill a fly with a
sledgehammer.' :)
>
>
> Your right though, the large sites need much
> > more abstraction.
>
>
> It probably comes down to, what is the fastest XPath engine and if
> the sitetree.xml is held within memory. I wonder what's the difference
> between XIndice and the Xalan XPath implementation?!
I find Saxon to be the fastest. It can handle very large XML files, quickly.
>
>
> As for maintainablity, we have users administer the site
> > through a GUI. They seem to love the explicit control.
>
>
> I can believe that. Do you have a screenshot of the user interface?
Why sure :) they are a little old, but here is the main interface:
http://www.livestoryboard.com/en_us/liveSTORYBOARD/screenshots/Storyboard.html
Most of the images are 3 months old. Much has been added/changed.
>
>
> What about rules for creating/deleting (moving) within the sitetree?
> For instance a certain doctype is related to some URI-pattern.
The user navigates the site and adds folders/pages/other-stuff where they are
located. On each page view in the tool I know the folder nodeset, and possibly
the page nodeset or the content nodeset. So when they are in sub-folder1 and
want to create a page or folder, the parameters are sent to the server and the
new item is placed in the hierarchy based on their current position.
If they want to move a folder or page, they lauch the respective properties
dialog and select a different folder from a drop down input. The server then
places the current nodeset in the new folder (at the top). I don't have an image
up for this but, if you could imagine the Add Folder dialog filled in and with a
'Folder Container' drop down at the bottom.
http://www.livestoryboard.com/en_us/liveSTORYBOARD/screenshots/Add_Folder.html
>
> Another issue I think would also be dynamic sitetrees (or parts of it),
> for instance in the case of a phone book: employees/employee-*-*.html
Definitely.
best,
-Rob
>
> All the best
>
> Michael
>
>
>
>
> >
> > best,
> > -Rob
> >
> >
> >
> > ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
> >
> > To unsubscribe, e-mail: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
> >
>
>
> --
> OSCOM - Open Source Content Management Conference
> September 25th - 27th 2002, Berkeley, California
> http://www.oscom.org/conferences/berkeley2002/
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Michael Wechner <mi...@wyona.org>.
Robert Koberg wrote:
> Hi Michael,
>
>
<snip/>
>>
>>An even more important issue is scalability (and related to it
>>performance) and maintenance of the sitetree.xml or whatever one wants
>>to call it.
>>
>>Did you ever try out your approach with more pages envolved, let's say
>>1000 or even a 1000000?
>>
>
> My approach would not work well with sites this large. But for 80% (?) of the
> sites out there it would work well.
It would be interesting to know the average size (number of pages),
resp. distribution of websites out there.
There's certainly no need to "break a butterfly on a wheel" (why do you
say that in english? In german you say "to shoot with cannons on sparrows")
Your right though, the large sites need much
> more abstraction.
It probably comes down to, what is the fastest XPath engine and if
the sitetree.xml is held within memory. I wonder what's the difference
between XIndice and the Xalan XPath implementation?!
As for maintainablity, we have users administer the site
> through a GUI. They seem to love the explicit control.
I can believe that. Do you have a screenshot of the user interface?
What about rules for creating/deleting (moving) within the sitetree?
For instance a certain doctype is related to some URI-pattern.
Another issue I think would also be dynamic sitetrees (or parts of it),
for instance in the case of a phone book: employees/employee-*-*.html
All the best
Michael
>
> best,
> -Rob
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
--
OSCOM - Open Source Content Management Conference
September 25th - 27th 2002, Berkeley, California
http://www.oscom.org/conferences/berkeley2002/
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Robert Koberg <ro...@koberg.com>.
Hi Michael,
> -----Original Message-----
> From: Michael Wechner [mailto:michael.wechner@wyona.org]
> Sent: Sunday, September 15, 2002 7:08 AM
> To: cocoon-users@xml.apache.org
> Subject: Re: About sitetrees and navigation bars (long post) (Was: Re:
> Link Livesites: Inventive Designers)
>
>
> Dear Litrik
>
> Thanks a lot for your detailed explanation.
>
> I think "book.xml" is used by the Forrest project
> (http://xml.apache.org/forrest) to generate their navigation and sitemap,
> but I am not sure, because I never found the time to check for myself.
>
> There are so many solutions out there with regard to the generation
> of navigation, bread-crumb-path and (web-)sitemap.
>
> It would be nice to consolidate on a common syntax and a common approach
> to map the URI-space onto some XML and in return to generate something else.
>
> Another issue is the relationship to topic-maps (somebody started a
> thread about topic-maps recently on forrest-dev).
>
> An even more important issue is scalability (and related to it
> performance) and maintenance of the sitetree.xml or whatever one wants
> to call it.
>
> Did you ever try out your approach with more pages envolved, let's say
> 1000 or even a 1000000?
My approach would not work well with sites this large. But for 80% (?) of the
sites out there it would work well. Your right though, the large sites need much
more abstraction. As for maintainablity, we have users administer the site
through a GUI. They seem to love the explicit control.
best,
-Rob
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Conal Tuohy <co...@paradise.net.nz>.
Michael wrote:
> Another issue is the relationship to topic-maps (somebody started a
> thread about topic-maps recently on forrest-dev).
For a project at work I've used a system similar to the one under
discussion, with a "site-definition" file containing <page> elements within
<page> elements, etc; here's an extract for the website, which is a
"scholarly" website about the history of the printing industry in Wellington
(the capital of NZ):
<site>
<page id="1880s" name="1880's" href="009">
<page-list name="Lyon & Blair">
<category name="Business History">
<page id="lyon-and-blair-1" href="081"/>
<page id="lyon-and-blair-2" href="078">
<extract tei-id="PHW-078-div1.1"/>
<extract tei-id="PHW-078-div1.2"/>
</page>
etc.
NB The actual content (i.e. books) is marked up in TEI format, and the
<extract> elements in the above file are pointers into the TEI documents.
But I've also been looking into topic maps, because they are a much more
general solution. Our website, www.nzetc.org, is a digital library, and over
time it will need to develop more sites focused on particular subsets of our
TEI corpus. The above site-definition file should map fairly easily onto a
topic map, something like:
site->topicmap
page->topic
category->role in association
extract->occurrence
Topic Maps are ideal for structuring information-rich websites because they
are layered on top of other resources of arbitrary types. A system like the
one I've used (above) is mostly page-oriented, but a Topic Map can impose a
real *conceptual* framework on top of these data, by "reifying" the
resources as "topics", which are typed, with multiple inheritance, and
scopes (which are a kind of "view" or aspect of a topic), with relationships
between the topics.
Each topic is then related to other topics with "associations". These
relationships between topics are themselves topics. So you can have a full
class-hierarchy of relationships too, which lets you model the relationships
at a number of levels:
* reflexive, transitive, etc,
* subclass-superclass, class-instance, collection-member, place-area, etc,
* author-work, work-citation, animal-species, city-country, etc.
Currently I'm looking at the TM4J topic-map engine, @ www.tm4j.org, which
uses the Apache Licence:
>TM4J is a topic map engine implemented entirely in Java.
>Topic maps are a standard paradigm for the interchange
>of knowledge structures. This project aims to produce a
>complete suite of tools for creating, processing and
>publishing topic map information.
In particular, it strikes me that TopicMap Query Language processor would
make an excellent Cocoon transformer similar to the SQLTransformer. This
would give Cocoon similar functionality to products like Omnigator.
I am hoping to use this technology (with Cocoon) in a new, very small,
project I have coming up over the next month or so. If anyone else is
interested, or already has some experience using TopicMaps with Cocoon (I
haven't), I'd be really keen to hear from them! I'm definitely going to
check out the reference to Topic Maps on forrest-dev!
Cheers!
Con
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Michael Wechner <mi...@wyona.org>.
Dear Litrik
Thanks a lot for your detailed explanation.
I think "book.xml" is used by the Forrest project
(http://xml.apache.org/forrest) to generate their navigation and sitemap,
but I am not sure, because I never found the time to check for myself.
There are so many solutions out there with regard to the generation
of navigation, bread-crumb-path and (web-)sitemap.
It would be nice to consolidate on a common syntax and a common approach
to map the URI-space onto some XML and in return to generate something else.
Another issue is the relationship to topic-maps (somebody started a
thread about topic-maps recently on forrest-dev).
An even more important issue is scalability (and related to it
performance) and maintenance of the sitetree.xml or whatever one wants
to call it.
Did you ever try out your approach with more pages envolved, let's say
1000 or even a 1000000?
Thanks
Michael
Litrik De Roy wrote:
> Michael,
>
> I don't know about the book.xml you mention but, I'll try to explain what I
> do..... ("Real programmers don't comment their code. If it was hard to
> write, it should be hard to understand.")
>
> All XSP pages have an attribute "uri" on my top element "Page". It
> identifies the page within the whole site and its the value is also what
> will guide the sitemap.xmap to this XSP. (I know... "uri" might not be the
> best name for the attribute but that's what it is called...)
>
> For example scriptura.xsp contains:
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> <?xml version="1.0"?>
> <xsp:page
> language="java"
> xmlns:xsp="http://apache.org/xsp"
>
> <Page uri="/products/scriptura.html">
> <Main>
> ...
> </Main>
> <Extra>
> ...
> </Extra>
> </Page>
> </xsp:page>
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
>
> This is what the sitetree.xml looks like:
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
>
> <?xml version="1.0"?>
> <Site uri="/welcome.html" title="Welcome" navbar="yes">
> <Page uri="/company.html" title="Company" navbar="yes">
> ...
> </Page>
> <Page uri="/products.html" title="Products" navbar="yes">
> <Page uri="/products/dtm.html" title="DTM for AS/400e Servers"
> navbar="yes">
> ...
> </Page>
> <Page uri="/products/scriptura.html" title="Scriptura" navbar="yes">
> <Page uri="/products/scriptura/overview.html" title="Overview"
> navbar="yes">
> <Page uri="/products/scriptura/overview/designer.html" title="Scriptura
> Designer"/>
> <Page uri="/products/scriptura/overview/engine.html" title="Scriptura
> Engine"/>
> </Page>
> ...
> </Page>
> ...
> </Page>
> ...
> <Page uri="/error404.html" title="Page not found" sitemap="no"/>
> <Page uri="/site/error-dl.html" title="Download Error" sitemap="no"/>
> </Site>
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> The "Site" contains nested "Page"s. Each "Page" has a "uri" that will be use
> to map against what is in the XSP, a "title", and possibly a navbar="yes" to
> indicate that this page should appear in the navigation bar, and possibly a
> sitemap="no" to indicate that this page should not appear in the sitemap.
>
> Here is a stripped down version of the stylesheet that converts my own XML
> to real HTML. Look at the following:
> - sitetree.xml gets included using the XSL document() function
> - variable "thispage" contains the uri of this page
> - variable "navbarpage" contains the uri of the youngest ancestor with a
> navbar attribute (this way pages with no navbar attribuet will be
> represented in the navigation bar by its parent or grandparent or....)
> - <title> shows how sitetree.xml is used to construct a title containg the
> parents of the page
> - the template "Navbar" constructs the navigation bar using the 5 XPath axis
> : ancestor, preceding-sibling, self, child, following-sibling
> - the template "NavbarItem" generates the HTML for an item in the navigation
> bar using the parameter "relation" to know whether it should generate a link
> or just text
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:output indent="no" method="html"/>
> <xsl:variable name="SiteTreeFile"
> select="document('../metadata/sitetree.xml')"/>
>
> <xsl:template match="Page">
> <xsl:variable name="thispage">
> <xsl:value-of select="@uri"/>
> </xsl:variable>
> <xsl:variable name="navbarpage">
> <xsl:value-of
> select="$SiteTreeFile//*[@uri=$thispage]/ancestor-or-self::*[@navbar][1]/@ur
> i"/>
> </xsl:variable>
> <html>
> <head>
> <title>Inventive Designers
> <xsl:for-each
> select="$SiteTreeFile//Page[@uri=$navbarpage]/ancestor-or-self::Page">
> - <xsl:value-of select="@title"/>
> </xsl:for-each>
> </title>
> ...
> <tr valign="top">
> <td>
> <table width="100%" cellspacing="0" cellpadding="0">
> <tr>
> <xsl:call-template name="Navbar">
> <xsl:with-param name="navbarpage"><xsl:value-of
> select="$navbarpage"/></xsl:with-param>
> </xsl:call-template>
> <xsl:apply-templates select="Main"/>
> <xsl:apply-templates select="Extra"/>
> </tr>
> </table>
> </td>
> </tr>
> ...
> </body>
> </html>
> </xsl:template>
>
> <xsl:template name="Navbar">
> <xsl:param name="navbarpage"/>
> <td class="Navbar">
> <p>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/ancestor::*[@navbar]">
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">ancestor</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/preceding-sibling::Page[@navbar]"
>
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">sibling</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each select="$SiteTreeFile//*[@uri=$navbarpage]">
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">current</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/child::Page[@navbar]">
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">child</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/following-sibling::Page[@navbar]"
>
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">sibling</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> </p>
> </td>
> </xsl:template>
>
> <xsl:template name="NavbarItem">
> <xsl:param name="relation"/>
> <xsl:choose>
> <xsl:when test="$relation='current'">
> <xsl:element name="p">
> <xsl:attribute name="class">NavbarItem</xsl:attribute>
> <xsl:attribute name="style">font-weight: bold ; margin-left:
> <xsl:value-of select="count(ancestor::*)"/>em ;</xsl:attribute>
> <xsl:element name="a">
> <xsl:attribute name="class">NavbarLink</xsl:attribute>
> <xsl:attribute name="href"><xsl:value-of
> select="@uri"/></xsl:attribute>
> <xsl:value-of select="@title"/>
> </xsl:element>
> </xsl:element>
> </xsl:when>
> <xsl:otherwise>
> <xsl:element name="p">
> <xsl:attribute name="style">margin-left: <xsl:value-of
> select="count(ancestor::*)"/>em;</xsl:attribute>
> <xsl:attribute name="class">NavbarItem</xsl:attribute>
> <xsl:element name="a">
> <xsl:attribute name="class">NavbarLink</xsl:attribute>
> <xsl:attribute name="href"><xsl:value-of
> select="@uri"/></xsl:attribute>
> <xsl:value-of select="@title"/>
> </xsl:element>
> </xsl:element>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:template>
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> And finally the same stylesheet also contains the code to generate the
> sitemap page:
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> <xsl:template match="Sitemap">
> <xsl:variable name="no">no</xsl:variable>
> <xsl:for-each select="$SiteTreeFile//*[not(@sitemap) or @sitemap!=$no]">
> <xsl:call-template name="SitemapItem">
> </xsl:call-template>
> </xsl:for-each>
> </xsl:template>
>
> <xsl:template name="SitemapItem">
> <xsl:element name="p">
> <xsl:attribute name="style">margin-left: <xsl:value-of
> select="count(ancestor::*) * 2"/>em;</xsl:attribute>
> <xsl:attribute name="class">SitemapItem</xsl:attribute>
> <xsl:element name="a">
> <xsl:attribute name="href"><xsl:value-of select="@uri"/></xsl:attribute>
> <xsl:value-of select="@title"/>
> </xsl:element>
> </xsl:element>
> </xsl:template>
>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> Litrik De Roy
> www.litrik.com
>
>
> ----- Original Message -----
> From: "Michael Wechner" <mi...@wyona.org>
> To: <co...@xml.apache.org>
> Sent: Sunday, September 15, 2002 1:26 PM
> Subject: Re: Link Livesites: Inventive Designers
>
>
>
>>
>>Litrik De Roy wrote:
>>
>>
>>>Inventive Designers (http://www.inventivedesigners.com/) is a belgian
>>>
>><snip/>
>>
>>>- A special sitetree.xml document and some complex XPath expressions for
>>>generating the navigation bar on each page, and the sitemap page.
>>>
>>
>>
>>Is it possible to take a look at your sitetree.xml? Is there any
>>relationship to the book.xml?
>>
>>Thanks
>>
>>Michael
>>
>>
>>
>>
>>
>>
>>
>>>- Lotus Domino for iSeries(AS/400) as the backend database for all FAQs,
>>>Events, Press Quotes. Access is done through the "Lotus Domino Toolkit
>>>
> for
>
>>>Java/CORBA".
>>>- iSeries(AS/400) for execution of some existing code. Access is done
>>>through the "IBM iSeries Toolbox for Java"
>>>
>>>
>>>Litrik De Roy
>>>www.litrik.com
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>Please check that your question has not already been answered in the
>>>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>>>
>>>To unsubscribe, e-mail: <co...@xml.apache.org>
>>>For additional commands, e-mail: <co...@xml.apache.org>
>>>
>>
>>--
>>OSCOM - Open Source Content Management Conference
>>September 25th - 27th 2002, Berkeley, California
>>http://www.oscom.org/conferences/berkeley2002/
>>
>>
>>---------------------------------------------------------------------
>>Please check that your question has not already been answered in the
>>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>>
>>To unsubscribe, e-mail: <co...@xml.apache.org>
>>For additional commands, e-mail: <co...@xml.apache.org>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
--
OSCOM - Open Source Content Management Conference
September 25th - 27th 2002, Berkeley, California
http://www.oscom.org/conferences/berkeley2002/
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Litrik De Roy <co...@litrik.com>.
----- Original Message -----
From: "Joerg Heinicke" <jo...@gmx.de>
To: <co...@xml.apache.org>
Sent: Sunday, September 15, 2002 10:58 PM
Subject: Re: About sitetrees and navigation bars (long post) (Was: Re: Link
Livesites: Inventive Designers)
> Hi Litrik,
>
> I want to suggest a more or less important change to your XSL. Have you
> thought about using keys? You are really often using //* with @uri as
> key. You only need to switch the context to the $SiteTreeFile to use the
> key there.
Ahum... I have to admit I never really looked at XPath "keys".
<interesting examples showing usage of keys>
>
> and so on. It should speed up your transformation a bit. The more
> entries in the $SiteTreeFile the bigger will be the advantage. But it
> will consume more memory to store the key index.
Thanks for the advice. Currently the $SiteTreeFile contains approx 50 pages
so performance is just fine. But I'll do some reading on XPath keys and give
it a try.
PS: The very first version had document() on each and every XPath
expression.... now, that really hurt performance. At least now the
document() is in a variable.
>
> Regards,
>
> Joerg
>
Litrik De Roy
www.litrik.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link
Livesites: Inventive Designers)
Posted by Joerg Heinicke <jo...@gmx.de>.
Hi Litrik,
I want to suggest a more or less important change to your XSL. Have you
thought about using keys? You are really often using //* with @uri as
key. You only need to switch the context to the $SiteTreeFile to use the
key there.
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <xsl:output indent="no" method="html"/>
<xsl:key name="pages" match="Page" use="@uri"/>
> <xsl:variable name="SiteTreeFile"
> select="document('../metadata/sitetree.xml')"/>
>
> <xsl:template match="Page">
> <xsl:variable name="thispage">
> <xsl:value-of select="@uri"/>
> </xsl:variable>
> <xsl:variable name="navbarpage">
replace
> <xsl:value-of
> select="$SiteTreeFile//*[@uri=$thispage]/ancestor-or-self::*[@navbar][1]/@ur
> i"/>
with
<xsl:for-each select="$SiteTreeFile">
<xsl:value-of select="key('pages', $thispage)
/ancestor-or-self::*[@navbar][1]/@uri"/>
</xsl:for-each>
> </xsl:variable>
> <html>
> <head>
> <title>Inventive Designers
replace
> <xsl:for-each
> select="$SiteTreeFile//Page[@uri=$navbarpage]/ancestor-or-self::Page">
> - <xsl:value-of select="@title"/>
> </xsl:for-each>
with
<xsl:for-each select="$SiteTreeFile">
<xsl:for-each select="key('pages', $navbarpage)
/ancestor-or-self::Page">
- <xsl:value-of select="@title"/>
</xsl:for-each>
</xsl:for-each>
...
and so on. It should speed up your transformation a bit. The more
entries in the $SiteTreeFile the bigger will be the advantage. But it
will consume more memory to store the key index.
Regards,
Joerg
> </title>
> ...
> <tr valign="top">
> <td>
> <table width="100%" cellspacing="0" cellpadding="0">
> <tr>
> <xsl:call-template name="Navbar">
> <xsl:with-param name="navbarpage"><xsl:value-of
> select="$navbarpage"/></xsl:with-param>
> </xsl:call-template>
> <xsl:apply-templates select="Main"/>
> <xsl:apply-templates select="Extra"/>
> </tr>
> </table>
> </td>
> </tr>
> ...
> </body>
> </html>
> </xsl:template>
>
> <xsl:template name="Navbar">
> <xsl:param name="navbarpage"/>
> <td class="Navbar">
> <p>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/ancestor::*[@navbar]">
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">ancestor</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/preceding-sibling::Page[@navbar]"
>
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">sibling</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each select="$SiteTreeFile//*[@uri=$navbarpage]">
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">current</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/child::Page[@navbar]">
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">child</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> <xsl:for-each
> select="$SiteTreeFile//*[@uri=$navbarpage]/following-sibling::Page[@navbar]"
>
> <xsl:call-template name="NavbarItem">
> <xsl:with-param name="relation">sibling</xsl:with-param>
> </xsl:call-template>
> </xsl:for-each>
> </p>
> </td>
> </xsl:template>
>
> <xsl:template name="NavbarItem">
> <xsl:param name="relation"/>
> <xsl:choose>
> <xsl:when test="$relation='current'">
> <xsl:element name="p">
> <xsl:attribute name="class">NavbarItem</xsl:attribute>
> <xsl:attribute name="style">font-weight: bold ; margin-left:
> <xsl:value-of select="count(ancestor::*)"/>em ;</xsl:attribute>
> <xsl:element name="a">
> <xsl:attribute name="class">NavbarLink</xsl:attribute>
> <xsl:attribute name="href"><xsl:value-of
> select="@uri"/></xsl:attribute>
> <xsl:value-of select="@title"/>
> </xsl:element>
> </xsl:element>
> </xsl:when>
> <xsl:otherwise>
> <xsl:element name="p">
> <xsl:attribute name="style">margin-left: <xsl:value-of
> select="count(ancestor::*)"/>em;</xsl:attribute>
> <xsl:attribute name="class">NavbarItem</xsl:attribute>
> <xsl:element name="a">
> <xsl:attribute name="class">NavbarLink</xsl:attribute>
> <xsl:attribute name="href"><xsl:value-of
> select="@uri"/></xsl:attribute>
> <xsl:value-of select="@title"/>
> </xsl:element>
> </xsl:element>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:template>
> ----8<--------8<--------8<--------8<--------8<--------8<--------8<----
>
> Litrik De Roy
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Litrik De Roy <co...@litrik.com>.
----- Original Message -----
From: "Robert Koberg" <ro...@koberg.com>
To: <co...@xml.apache.org>
Sent: Monday, September 16, 2002 8:54 PM
Subject: RE: About sitetrees and navigation bars (long post) (Was: Re: Link
Livesites: Inventive Designers)
<snip/>
> >
> > I don't really see the difference. I nest Pages, you use Folders to
> > represent Pages that contain other Pages. It's just a matter of
terminology.
> > I prefer the word "Page" because that's what it really is... a page (on
a
> > web site). It's just a matter of terminology.
>
> Well, the difference is you hard code your folder names into your URI
> attributes. If the folder or it's name changes you have to redo your
attributes.
> You do not need to do this if you keep 'pages' in 'folders.' I have been
usinig
> site trees for 3-4 years (my latest incarnation for about a year) now and
this
> is what I have come to find. It has been like bouncing off the walls of a
funnel
> to fall out the bottom to my goal.
>
> What if your index page changes? You have to reconfigure your XML, while I
just
> have to change an attribute.
>
Well I guess that for my site that is not really an issue. The site's main
structure has been stable for more than 3 years now. Your approach is indeed
better if there are lots of "Folders", and the structure or index pages
change a lot.
Not really applicable to my type of site. But I'll keep this in mind.
<snip/>
>
> >
> > > -- Internal links can reference a page or folder ID and be assured it
will
> > have
> > > the correct path, even if the page or folder was moved.
> >
> > In the very first version I also used the term "ID" to identify a page.
By
> > definition the ID had to be unique within the site. For example the
product
> > overview of Scriptura would have id="scriptura-overview", the overview
of
> > EverGreen/400 would have id="evergreen-overview". Now... if you want to
keep
> > meaningful names and the structure of the web site is a number of levels
> > deep, you end up with an ID that maps to the URL of the page. As soon as
I
> > noticed that I decided to use the URL (or URI (?) ... I always get
confused
> > by the terminology). A visitor to the website knows that the overview of
> > Scriptura can be found at "/products/scriptura/overview.html"....
well... I
> > use the same ID internally.
>
> If you need descriptive page names then use a label attribute (if I
understand
> you correctly). The path_builder example I gave as in the xsl examples
uses an
> root element attribute to determine what kind of page name to use, the id
or the
> label. If it is the label, I send it through some templates to strip
quotes and
> replace spaces with underscores.
>
> You can also use the label attribute for your navigation.
> <snip/>
>
In the end there really is not a big difference. In fact if, one day, I
would decide to add more flexibilty to the sitetree using the techniques you
described, it would be fairly easy.
It just shows how flexible XML and XPath can be.
> best,
> -Rob
>
Litrik De Roy
www.litrik.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Robert Koberg <ro...@koberg.com>.
Hi
> -----Original Message-----
> From: Litrik De Roy [mailto:cocoon-users@litrik.com]
> Sent: Monday, September 16, 2002 10:47 AM
> ----- Original Message -----
> From: "Robert Koberg" <ro...@koberg.com>
> Sent: Sunday, September 15, 2002 4:02 PM
> > Hi,
> >
> > > -----Original Message-----
> > > From: Litrik De Roy [mailto:cocoon-users@litrik.com]
> > > Sent: Sunday, September 15, 2002 6:07 AM
> > >
> > > All XSP pages have an attribute "uri" on my top element "Page". It
> > > identifies the page within the whole site and its the value is also what
> > > will guide the sitemap.xmap to this XSP. (I know... "uri" might not be
> the
> > > best name for the attribute but that's what it is called...)
> >
> > You could organize your Page elements inside Folder elements and eliminate
> the
> > need for your uri attribute. You can crawl up and down the pages and
> folders to
> > build paths.
>
> I don't really see the difference. I nest Pages, you use Folders to
> represent Pages that contain other Pages. It's just a matter of terminology.
> I prefer the word "Page" because that's what it really is... a page (on a
> web site). It's just a matter of terminology.
Well, the difference is you hard code your folder names into your URI
attributes. If the folder or it's name changes you have to redo your attributes.
You do not need to do this if you keep 'pages' in 'folders.' I have been usinig
site trees for 3-4 years (my latest incarnation for about a year) now and this
is what I have come to find. It has been like bouncing off the walls of a funnel
to fall out the bottom to my goal.
What if your index page changes? You have to reconfigure your XML, while I just
have to change an attribute.
>
> >
> > I will use an example from what I do. The snipped XML (there are more
> elements)
> > below allows for several things:
> >
> > - you can build links very easy and maintain integrity.
> > -- The nav can be built in a numbver of ways by crawling the site tree.
>
> That's exactly what I do as well.
No, not really. As I mentioned earlier you hard code folder names into your
page/@uri's
>
> > -- Internal links can reference a page or folder ID and be assured it will
> have
> > the correct path, even if the page or folder was moved.
>
> In the very first version I also used the term "ID" to identify a page. By
> definition the ID had to be unique within the site. For example the product
> overview of Scriptura would have id="scriptura-overview", the overview of
> EverGreen/400 would have id="evergreen-overview". Now... if you want to keep
> meaningful names and the structure of the web site is a number of levels
> deep, you end up with an ID that maps to the URL of the page. As soon as I
> noticed that I decided to use the URL (or URI (?) ... I always get confused
> by the terminology). A visitor to the website knows that the overview of
> Scriptura can be found at "/products/scriptura/overview.html".... well... I
> use the same ID internally.
If you need descriptive page names then use a label attribute (if I understand
you correctly). The path_builder example I gave as in the xsl examples uses an
root element attribute to determine what kind of page name to use, the id or the
label. If it is the label, I send it through some templates to strip quotes and
replace spaces with underscores.
You can also use the label attribute for your navigation.
<snip/>
best,
-Rob
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Litrik De Roy <co...@litrik.com>.
----- Original Message -----
From: "Robert Koberg" <ro...@koberg.com>
To: <co...@xml.apache.org>
Sent: Sunday, September 15, 2002 4:02 PM
Subject: RE: About sitetrees and navigation bars (long post) (Was: Re: Link
Livesites: Inventive Designers)
> Hi,
>
> > -----Original Message-----
> > From: Litrik De Roy [mailto:cocoon-users@litrik.com]
> > Sent: Sunday, September 15, 2002 6:07 AM
> >
> > All XSP pages have an attribute "uri" on my top element "Page". It
> > identifies the page within the whole site and its the value is also what
> > will guide the sitemap.xmap to this XSP. (I know... "uri" might not be
the
> > best name for the attribute but that's what it is called...)
>
> You could organize your Page elements inside Folder elements and eliminate
the
> need for your uri attribute. You can crawl up and down the pages and
folders to
> build paths.
I don't really see the difference. I nest Pages, you use Folders to
represent Pages that contain other Pages. It's just a matter of terminology.
I prefer the word "Page" because that's what it really is... a page (on a
web site). It's just a matter of terminology.
>
> I will use an example from what I do. The snipped XML (there are more
elements)
> below allows for several things:
>
> - you can build links very easy and maintain integrity.
> -- The nav can be built in a numbver of ways by crawling the site tree.
That's exactly what I do as well.
> -- Internal links can reference a page or folder ID and be assured it will
have
> the correct path, even if the page or folder was moved.
In the very first version I also used the term "ID" to identify a page. By
definition the ID had to be unique within the site. For example the product
overview of Scriptura would have id="scriptura-overview", the overview of
EverGreen/400 would have id="evergreen-overview". Now... if you want to keep
meaningful names and the structure of the web site is a number of levels
deep, you end up with an ID that maps to the URL of the page. As soon as I
noticed that I decided to use the URL (or URI (?) ... I always get confused
by the terminology). A visitor to the website knows that the overview of
Scriptura can be found at "/products/scriptura/overview.html".... well... I
use the same ID internally.
> - you can assign a 'site index' and 'folder index' pages to identify at
> generation time and to copy to index.html in the proper location, a
dynamic site
> can use this page when a folder link is clicked on.
> - you can set different attributes to trigger XSLT components (TOC,
snailtrail,
> pagination, etc) to be accessed.
> - you can assign an XSL at the folder level and it can cascade down to
pages
> unless overriden at the page level
> - you can assign content pieces at the folder and page level in different
> columns. If assigned at the folder level it is displayed on all pages in
the
> folder. (content pieces are a reference to an entry in a content.xml
config file
> that describes them more)
> - you can set status at the folder and page level (you set status for a
content
> piece in content.xml)
Even though I don't have all this today, I could do the same thing in my
'architecture'. The only difference is the terminology nested "Pages" versus
"Pages" within "Folders".
In fact today I have added something that fits your descriptions above. I
added new attributes "keywords" and "description" on a page. I use these
attributes to set the metadata tags to help search engines. And the
principle is always the same. If the attribute does not exist I move up the
ancestors axis the find them.
<interesting examples removed>
>
> best,
> -Rob
>
>
We are basically doing the same thing.
Litrik De Roy
www.litrik.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: About sitetrees and navigation bars (long post) (Was: Re: Link Livesites: Inventive Designers)
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Litrik De Roy [mailto:cocoon-users@litrik.com]
> Sent: Sunday, September 15, 2002 6:07 AM
>
> All XSP pages have an attribute "uri" on my top element "Page". It
> identifies the page within the whole site and its the value is also what
> will guide the sitemap.xmap to this XSP. (I know... "uri" might not be the
> best name for the attribute but that's what it is called...)
You could organize your Page elements inside Folder elements and eliminate the
need for your uri attribute. You can crawl up and down the pages and folders to
build paths.
I will use an example from what I do. The snipped XML (there are more elements)
below allows for several things:
- you can build links very easy and maintain integrity.
-- The nav can be built in a numbver of ways by crawling the site tree.
-- Internal links can reference a page or folder ID and be assured it will have
the correct path, even if the page or folder was moved.
- you can assign a 'site index' and 'folder index' pages to identify at
generation time and to copy to index.html in the proper location, a dynamic site
can use this page when a folder link is clicked on.
- you can set different attributes to trigger XSLT components (TOC, snailtrail,
pagination, etc) to be accessed.
- you can assign an XSL at the folder level and it can cascade down to pages
unless overriden at the page level
- you can assign content pieces at the folder and page level in different
columns. If assigned at the folder level it is displayed on all pages in the
folder. (content pieces are a reference to an entry in a content.xml config file
that describes them more)
- you can set status at the folder and page level (you set status for a content
piece in content.xml)
I have to create two sets of navs for the livestoryboard tool. One for the tool
and one for a generated site. The XSLT below shows how I use the site tree xml
to create relative HTML links and javascript: links. I use two URIResolvers
depending on whether the user is in authoring time or generating the site to
static. During tool time the URIResolver resolves util XSLT files to the tool's
set and during generation in resolves to the client's set.
I have an entire site/example up at
http://docs.livestoryboard.com/en_us/manual/Overview.html (though the URL says
docs, there is not too much there yet :( ). And it is a little out of date. I
will have a newer version up in a few days, but it shows many examples of how
the site tree xml can be used.
First an XML snippet (followed by some XSLT):
<config id="clean" nav_col="tabs_narrow_left" p_nam="label"
site_index="siteindex" subtitle="Starter1" title="Clean Site1"
use_tool_style="0">
<folder display_label_link="true" expand="true" id="f1" index_page="siteindex"
label="Home" name="en_us" pager="true" snailtrail="true" status="editorial"
xsl_fileref="basic_3col.xsl">
<col type="narrow_right">
<article id="c413186147"/>
</col>
<page display_label_link="true" file_ext=".html" gen="true" id="siteindex"
label="index" metadata="true" print_friendly="true" status="editorial"
title="Clean Index Page" toc="true" xsl_fileref="homepage.xsl">
<col type="narrow_left"/>
<col type="wide_center">
<article id="cindex"/>
<article id="c1021039099"/>
</col>
<col type="narrow_right"/>
</page>
<page display_label_link="true" file_ext=".html" gen="true" id="p353715906"
label="page 2" metadata="false" print_friendly="true" status="editorial"
title="page 2" toc="false" xsl_fileref="basic_3col.xsl">
<col type="narrow_left"/>
<col type="wide_center">
<article id="c1919458443"/>
<article id="cindex"/>
</col>
<col type="narrow_right"/>
</page>
<folder display_label_link="true" expand="false" id="f953036460"
index_page="p948884099" label="Folder 1" name="Folder1" pager="true"
snailtrail="true" status="editorial" xsl_fileref="basic_3col.xsl">
<col type="narrow_left"/>
<col type="wide_center"/>
<col type="narrow_right"/>
<page display_label_link="true" file_ext=".html" gen="true" id="p948884099"
label="page 1" metadata="true" print_friendly="true" status="editorial"
title="page 1" toc="true" xsl_fileref="basic_2col.xsl">
<col type="narrow_left"/>
<col type="wide_center">
<article id="c413186147"/>
<article id="cindex"/>
</col>
<col type="narrow_right"/>
</page>
<folder display_label_link="true" expand="false" id="f1051775540"
index_page="p1113453353" label="Folder1a" name="f1a" pager="false"
snailtrail="true" status="editorial" xsl_fileref="basic_3col.xsl">
<col type="narrow_left"/>
<col type="wide_center"/>
<col type="narrow_right"/>
<page display_label_link="true" file_ext=".html" gen="true" id="p1113453353"
label="fdsfasfd" metadata="false" print_friendly="false" status="editorial"
title="sdfadfaf" toc="false" xsl_fileref="basic_3col.xsl">
<col type="narrow_left"/>
<col type="wide_center">
<article id="c1021039099"/>
</col>
<col type="narrow_right"/>
</page>
</folder>
</folder>
....
<snip/>
----------------------------------
An XSLT snippet for a nav:
<!-- I use more than one folder type so I set up a key to define them only
once -->
<xsl:key
name="folder-match-set"
match="folder | faqs | category | jobs | press_releases"
use="'folder-types'" />
<xsl:template match="key('folder-match-set', 'folder-types')" mode="nav">
<xsl:variable name="folder_label" select="@label"/>
<xsl:variable name="folder_name" select="@name"/>
<xsl:variable name="folder_id" select="@id"/>
<xsl:variable name="_href">
<xsl:call-template name="folder_path_builder"/>
</xsl:variable>
<ul id="{generate-id()}" class="open">
<xsl:choose>
<xsl:when test="$folder_id=$folder_idref">
<a href="{$_href}" class="focus" title="{@title}">
<xsl:value-of select="$folder_label"/>
</a>
<xsl:apply-templates select="col" mode="nav"/>
<xsl:apply-templates select="*[not(name()='col')]" mode="nav"/>
</xsl:when>
<xsl:when test="descendant::*[@id=$folder_idref]">
<a href="{$_href}" class="focus" title="{@title}">
<xsl:value-of select="$folder_label"/>
</a>
<xsl:apply-templates select="*[not(name()='col')]" mode="nav"/>
</xsl:when>
<xsl:otherwise>
<a href="{$_href}" class="blur" title="{@title}">
<xsl:value-of select="$folder_label"/>
</a>
</xsl:otherwise>
</xsl:choose>
</ul>
</xsl:template>
<xsl:template match="page" mode="nav">
<xsl:variable name="_href">
<xsl:call-template name="page_path_builder"/>
</xsl:variable>
<ul class="open">
<xsl:choose>
<xsl:when test="not(@id=$page_idref)">
<a href="{$_href}" class="blur" title="{@title}">
<xsl:value-of select="@label"/>
</a>
</xsl:when>
<xsl:otherwise>
<a href="{$_href}" class="focus" title="{@title}">
<xsl:value-of select="@label"/>
</a>
<xsl:apply-templates select="col" mode="nav"/>
</xsl:otherwise>
</xsl:choose>
</ul>
</xsl:template>
------------------
Following are two ways to make links. The first creates regular, relative html
links. The second creates javascript: links for a dynamic app
(livestoryboard.com)
========= html links /tool/client-site/WEB-INF/styling/common/path_builders.xsl
=================
<xsl:template name="folder_path_builder">
<xsl:variable name="index_id" select="@index_page"/>
<xsl:variable name="index_page" select="page[@id=$index_id]"/>
<xsl:value-of select="$relative_path_to_root"/>
<xsl:choose>
<xsl:when test="not($root_nodeset/@site_index=$index_page/@id)">
<xsl:for-each select="ancestor::*[name()!='config']">
<xsl:if test="not(position()=1)">
<xsl:text>/</xsl:text>
</xsl:if>
<xsl:value-of select="@name"/>
</xsl:for-each>
<xsl:text>/</xsl:text>
<xsl:value-of select="@name"/>
<xsl:text>/</xsl:text>
<xsl:choose>
<xsl:when test="boolean($index_page)">
<xsl:choose>
<xsl:when test="$page_name_type='id'">
<xsl:value-of select="$index_page/@id"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="translate($index_page/@label, ' ', '_')"/>
</xsl:otherwise>
</xsl:choose>
<xsl:value-of select="$index_page/@file_ext"/>
</xsl:when>
<xsl:otherwise>
<xsl:choose>
<xsl:when test="$page_name_type='id'">
<xsl:value-of select="@id"/>
</xsl:when>
<xsl:otherwise>
<xsl:call-template name="remove_quotes">
<xsl:with-param name="string" select="translate(@label, ' ',
'_')"/>
</xsl:call-template>
</xsl:otherwise>
</xsl:choose>
<xsl:value-of select="'.html'"/>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:text>index</xsl:text>
<xsl:value-of select="$index_page/@file_ext"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template name="page_path_builder">
<xsl:value-of select="$relative_path_to_root"/>
<xsl:choose>
<xsl:when test="not($root_nodeset/@site_index=@id)">
<xsl:for-each select="ancestor::folder">
<xsl:if test="not(position()=1)">
<xsl:text>/</xsl:text>
</xsl:if>
<xsl:value-of select="@name"/>
</xsl:for-each>
<xsl:text>/</xsl:text>
<xsl:choose>
<xsl:when test="$page_name_type='id'">
<xsl:value-of select="@id"/>
</xsl:when>
<xsl:otherwise>
<xsl:call-template name="remove_quotes">
<xsl:with-param name="string" select="translate(@label, ' ', '_')"/>
</xsl:call-template>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:text>index</xsl:text>
</xsl:otherwise>
</xsl:choose>
<xsl:value-of select="@file_ext"/>
</xsl:template>
========== javascript: links /tool/WEB-INF/styling/common/path_builders.xsl
====================
<xsl:template name="folder_path_builder">
<xsl:variable name="folder_label" select="@label"/>
<xsl:variable name="folder_name" select="@name"/>
<xsl:variable name="folder_id" select="@id"/>
<xsl:variable name="index_id" select="@index_page"/>
<xsl:variable name="index_node_name" select="name(key('site_config_key',
@index_page))"/>
<xsl:variable name="index_xsl_fileref" select="key('site_config_key',
@index_page)/@xsl_fileref"/>
<xsl:variable name="style_fileref">
<xsl:choose>
<xsl:when test="$index_xsl_fileref='default'">
<xsl:value-of select="@xsl_fileref"/>
</xsl:when>
<xsl:when test="not($index_node_name='folder')">
<xsl:apply-templates select="." mode="get_default_styling"/>
</xsl:when>
<xsl:when test="$index_id='empty'">
<xsl:value-of select="@xsl_fileref"/>
</xsl:when>
<xsl:when test="@xsl_fileref='default'">
<xsl:apply-templates select="$folder_nodeset"
mode="get_default_styling"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$index_xsl_fileref"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:if test="not($type='ToolNav')">
<xsl:text>javascript:</xsl:text>
</xsl:if>
<xsl:value-of select="$cleanup_current_page_call"/>
<xsl:if test="$type='ToolNav'">
<xsl:text>_main.</xsl:text>
</xsl:if>
<xsl:text>displayPage('</xsl:text>
<xsl:value-of select="$folder_id"/>
<xsl:text>','</xsl:text>
<xsl:value-of select="$index_id"/>
<xsl:text>','','</xsl:text>
<xsl:value-of select="$style_fileref"/>
<xsl:text>')</xsl:text>
</xsl:template>
<xsl:template name="page_path_builder">
<xsl:variable name="current_page_idref" select="@id"/>
<xsl:variable name="style_fileref">
<xsl:choose>
<xsl:when test="@xsl_fileref='default'">
<xsl:apply-templates select="key('site_config_key', ../@id)"
mode="get_default_styling"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="@xsl_fileref"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:if test="not($type='ToolNav')">
<xsl:text>javascript:</xsl:text>
</xsl:if>
<xsl:value-of select="$cleanup_current_page_call"/>
<xsl:if test="$type='ToolNav'">
<xsl:text>_main.</xsl:text>
</xsl:if>
<xsl:text>displayPage('</xsl:text>
<xsl:value-of select="../@id"/>
<xsl:text>','</xsl:text>
<xsl:value-of select="$current_page_idref"/>
<xsl:text>','','</xsl:text>
<xsl:value-of select="$style_fileref"/>
<xsl:text>')</xsl:text>
</xsl:template>
best,
-Rob
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>