Morning,
> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi
> Sent: Saturday, October 11, 2003 2:35 PM
> To: [EMAIL PROTECTED]
<snip/>
> > I will try to give you something to chew on. Here is an example page
> (our
> > homepage):
> >
> > <site css="default.css" id="wwwuser" index_page="p1395893912" onnav="0"
> > xsl="default">
> > <label>Site</label>
> > <title>liveSTORYBOARD Content Management System: </title>
> > <page css="inherit" generate="1" id="p1395893912" name="Welcome.html"
> > onnav="1" pgstatus="publish" print_friendly="0" xsl="homepage">
> > <label>Home</label>
> > <title>Simple, powerful and secure hosted Web Content
> Management</title>
> > <regions>
> > <region name="wide_col">
> > <item ref="a1095201465"></item>
> > <item ref="c404932357"></item>
> > </region>
> > <region name="narrow1_col">
> > <item ref="c1109515213"></item>
> > <item ref="c108879656"></item>
> > </region>
> > </regions>
> > </page>
> > </
> >
> > Note the /site/page/regions/region elements. The region/@name reference
> a
> > page layout identifier like div/@id. The //region/item/@ref references
> an
> > XML document in a content repository.
> >
> > I currently call these in transformation using the document function.
>
> Hmmm, wait a sec, you are basically using site.xml to drive the site
> generation... the current site.xml would eventually do the same till the
> page tag, but without the things you put in that tag.
>
> What I would do instead, is to make a welcome.xml page and write inside
> it the xincludes I need...
OK, I see.
> but wait, you say that the name is the page
> layout identifier... what's a page layout identifier?
The region/@name simply tells the transformation where to stick the content.
For example, in the template below you see that I put those items that are
in the 'narrow_1col' region in an html
[EMAIL PROTECTED]'rightColumn']/[EMAIL PROTECTED]'floater'] and so on. You will also
notice
that some boolean tests are done, based on folder and page attributes, to
display certain UI features.
<xsl:template match="/">
<html>
<xsl:call-template name="head"/>
<body>
<xsl:call-template name="banner"/>
<div id="pageBody">
<div id="rightColumn">
<xsl:call-template name="nav"/>
<div class="floater">
<xsl:apply-templates
select="$lsb_folder_nodeset/lsb:regions/lsb:[EMAIL PROTECTED]'narrow1_col']/*"
mode="load_columns"/>
<xsl:apply-templates
select="$lsb_page_nodeset/lsb:regions/lsb:[EMAIL PROTECTED]'narrow1_col']/*"
mode="load_columns"/>
</div>
</div>
<div id="wideColumn">
<xsl:if test="$lsb_folder_snailtrail">
<xsl:call-template name="snailtrail"/>
</xsl:if>
<xsl:if test="$lsb_folder_pager">
<xsl:call-template name="pager"/>
</xsl:if>
<xsl:apply-templates select="$lsb_page_nodeset/lsb:title"/>
<xsl:if test="$lsb_page_print_friendly">
<xsl:call-template name="pf_link"/>
</xsl:if>
<xsl:apply-templates
select="$lsb_folder_nodeset/lsb:regions/lsb:[EMAIL PROTECTED]'wide_col']/*"
mode="load_columns"/>
<xsl:apply-templates
select="$lsb_page_nodeset/lsb:regions/lsb:[EMAIL PROTECTED]'wide_col']/*"
mode="load_columns"/>
<xsl:if test="$lsb_folder_pager">
<xsl:call-template name="pager"/>
</xsl:if>
</div>
</div>
<xsl:call-template name="footer"/>
</body>
</html>
</xsl:template>
>
> What does the above thing in practice generate as a result?
Well, it (site.xml) does not generate anything. It is used as the main
Source in a transformation. Additional information like the focus page ID
and its parent ID are sent to the transformation that tells the
transformation what the focus is. Global variables are setup from this
information (i.e. $lsb_page_nodeset).
By using the entire site.xml as the Source I can resolve all links
accurately and provide for other UI things for our CMS like a dropdown to
select a page to link to.
There are two ways to handle it, as I see it:
1) [what I currently do] pass the focus IDs into the transformation as
parameters and use the site.xml as the main Source and use the document
function along with URIResolvers to 'find' the content associated with the
region/item/@ref
2) run the site.xml through an XMLReader, strip out unnecessary stuff,
replace the item/@ref with the actual content piece, use XMLfilters to add
the stuff I am currently passing in with parameters and perform the
transformation.
>
> > Recently, I have been playing around with a XincludeFilter that does
> this
> > prior to transformation (I assume this is the route you would take :).
> It is
> > just that it is proving to be slower and more memory intensive for some
> > reason (I am probably doing wrong...).
>
> IIRC cinclude is more appropriate for server-side includes, and is also
> cacheable (don't remember if they made xinclude cacheable yet).
I still have some learning/investigating to do...
>
> > Use the site.xml in a ContentHandler or a class that traverses the
> site.xml
> > as a JDOM Element (or whatever) to generate the static pages. Our site
> is
> > approaching 500 pages (most with print friendly versions) and it takes
> 6-8
> > seconds to generate everything.
>
> Wait a sec, you generate the whole 500-page site with Cocoon (or just
> xslts?) in 8 seconds? I mean all the pages?
Not currently with cocoon. I am investigating using it for the 2cnd way I
described above (but, after just reading Bruno's reply, I don't know...).
Currently, as I keep the site.xml as a JDOM Element and just run through the
tree, create folders for the folder elements and generate/transform pages
(regular and print friendly) for the page elements.
In addition, it is relatively simple to transform the site.xml to an Ant
build file along with a catalog for content/xsl:include resolution so a site
can be generated offline -- which makes for a good exit strategy for our
clients.
And yes, all pages in usually less than 8 seconds (slower using Ant). In
addition, assets (images and other binaries) are synched. Most of our sites
(we are an ASP CMS) are small (under 100 pages) and they access their
projects relatively infrequently (I think of it like a health club business
model :) so this approach has not been problematic. But, for some reason, we
are getting more clients with monster sized sites and I want to do away with
the JDOM and use a SAX based approach. I have done this on my own, but it
was slower and more memory intensive. Hopefully using cocoon best practices
will give me more of what I am looking for. I don't know...
>
> Gosh, it's not fair, I have to sleep now and you got my brain thinking! ;-
> P
Cool :)
Best,
-Rob
>
> --
> Nicola Ken Barozzi [EMAIL PROTECTED]
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
