forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <>
Subject RE: extending site.xml -> was -> RE: directory/menu structure
Date Tue, 08 Apr 2003 23:14:53 GMT

[this is also a response to the wyona guy who responded - sorry, can't find
the email]

> -----Original Message-----
> From: Jeff Turner []
> Sent: Tuesday, April 08, 2003 9:58 AM
> Forrest currently has a very weakly defined data model (skinconf.xml +
>  Forrest's structural model (site layout) is defined
> in a very diffuse form in the Cocoon sitemap.  The site.xml file is
> purely there to define menus.  We could infer the whole of site.xml from
> filesystem + sitemap.

But the filesystem does not exist. In other words, the site.xml is a virtual
representation of the site at a particular moment in time. There would not
be anything to draw the metadata from. A generation mechanism crawls this
virtual filesystem (site.xml) to create the actual filesystem that lives in
a certain stage (dev, qa, cert, live). 

As I mentioned a few months ago, I did start out using a real structure,
crawling that to build up the site.xml at startup. But when using this
method in conjunction with a versioning system I had a maintainence
nightmare keeping everything in sync.

> By contrast, LSB seems to have the structural and data models all tightly
> defined in site.xml.  As you say, great for storyboarding, but can
> Forrest really use the same thing?

I think it would be a boon to real world situations which are fluid, not
just converting an already existing site that does not change. 

> 1) Structural implications
> Forrest can't do that, because the sitemap is central to how Forrest
> works.  Forrest's site.xml can _never_ drive things in the way LSB's
> does.

Probably. But why does Forrest have to be so tied to cocoon as-it-is, which
is designed for dynamic, massively scalable applications. That has nothing
to do with Forrest.

Could there be some way to utilize the nicely SoC'ed things of cocoon in an
environment outside of cocoon? Something that focuses not on massively
scalable, dynamic application, but the building of any kind of static sites.

> 2) Data model implications
> As I said above, Forrest's data model is very weakly defined, and we need
> to fix this, but this needs to be done by improving Forrest, not by
> grafting on LSB's solution.  Let's say we give site.xml nodes a @css
> attribute.  Where did it come from?  What do we do with it?  How does it
> interact with each skin's CSS?  The LSB answer doesn't apply to Forrest.

Something like:
<style type="text/css" media="all">
  @import "<xsl:value-of select="$relative_path"/>css/default.css";

<xsl:variable name="opt_css" select="$focus_nodeset/@css"/>
<xsl:if test="not($opt_css='css_default')">
  <style type="text/css" media="all">
    <xsl:variable name="opt_css_path">
      <xsl:apply-templates select="key('site', $opt_css)"
    @import "<xsl:value-of select="$relative_path"/><xsl:value-of

Some explanation of the variables used above:
$focus_nodeset is the site.xml node that is currently being generated
$relative_path is a dotdot path built based on the depth of the

> We've currently got skinconf.xml as our data model; we can throw it away,
> but need a fully explored alternative first.  Where does skinconf info
> (project name, url, images, copyrights, credits) go in the LSB model?
> Somewhere in the root of site.xml?  Sure, we can do that, but the
> question needs to be addressed holistically [1].

OK. That's my problem here too :) I guess I am looking for an offline
version of cocoon that is much more flexible.

> Hence the blank expressions - I cannot express opinions on fundamental
> issues in the form of criticism or approval of an XML format.
> So I'd like to take one specific, practical aspect of your site.xml
> suggestion: that of improving menus, and focus on that in my next email.

Sounds good. 

> Anyway, thanks for taking the trouble to write up the email I'm
> complaining about -- it's very good to have one's assumptions challenged
> :)

Thanks for the responses,

> --Jeff
> [1] "addressed holistically" is a phrase meaning "buggered if I know
> how".

View raw message