On Tue, Apr 08, 2003 at 04:14:53PM -0700, Robert Koberg wrote:
> [this is also a response to the wyona guy who responded - sorry, can't find
> the email]
> > -----Original Message-----
> > From: Jeff Turner [mailto:firstname.lastname@example.org]
> > Sent: Tuesday, April 08, 2003 9:58 AM
> > Forrest currently has a very weakly defined data model (skinconf.xml +
> > forrest.properties). 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).
Oh I see. I was thinking of it the other way: XML files being the
'filesystem'. If they contain some DC metadata, we could infer most of
site.xml from them and the sitemap. I'm not saying we should, just
illustrating the point that Forrest's site.xml is very much secondary to
the Cocoon sitemap.
> 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.
Cocoon just seems to be the tool currently best for the job. If
something better turns up, we'll use it. Right now, the only other
contender seems to be Jelly, which can do the job of Ant and XSLT.
> > 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:
> 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
That translates into allowing content writers to specify the
presentational style. Shouldn't that be the job of skin writers?
> Thanks for the responses,