forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Where is the line betweenForrest and a CMS (Re: vague issues with Forrest use)
Date Mon, 07 Nov 2005 20:33:48 GMT
Paul Bolger wrote:
> So, what is the function of site.xml, if it's not to do the above? 

Please be careful with your snipping of mails. The above sentence is 
meaningless in the context of the archives. I've made it worse by moving 
this to a new thread (something we should have done as soon as we 
started discussing this aspect of the original thread).

First let me try to bring some context back for archive readers:

This discussion has been exploring ways of making Forrest easier for new 
users. One suggestion is to provide an interface to manage the site.xml 
file. My own response to this suggestion is that Forrest is an XML 
publishing framework and not a CMS. It should not concern itself with 
how the site structure is managed, only with how it is used to publish 
the content. I suggest that we should focus on integration with CMS 
systems, which are responsible for the management of content. This is 
about where we have got to so far.

Now, to answer te above question:

site.xml is an internal (to Forrest) representation of the navigation 
structure within a Forrest published content object. It does not, 
necessarily, bear any relation to the document used in whatever system 
is used to manae the content, it is only relevant to Forrest.

This is akin to our internal XDoc format for documents and provides us 
with a standard document from which we can generate different types of 
content object rendering. For example, we may have the left navigation 
bar in a web site, or the contents list in a wholesite PDF.

OF course, many people actually write the site.xml file and use it as 
the source for their content object as well. But this is not required. 
Cocoon, for example, uses a daisy CMS to manage their content, and 
Burrokeet uses an IMS manifest.

> I'm
> a bit confused over the definition of CMS being used here - I'm used
> to it being used to refer to a system which does the lot - user input,
> site and database management, output formats, conversions, archiving,
> etc.

Can you point to a CMS that supports the wide range of input and output 
formats that Forrest supports? I certainly can't.

> If Daisy did do this Forrest would be redundant. I've been assuming
> that, broadly, we are referring to a CMS as an input module, and
> Forrest as an output module. This separation makes a lot of sense to
> me.

Yes, that is how I see it too.

> I think my original point was that if one wanted to used Forrest as a
> site generator, and the input files are a directory of Ooo docs, or
> whatever, it might be appropriate to have a Cocoon forms interface
> where a user who was intimidated by modifying XML config files could
> setup the structure of the output site. I'm trying to think in terms
> of how Forrest could be useful on a small scale. Once people are used
> to the concepts introduce them to more upscale applications involving
> databases and Servlets.

Yes, I can see this is a useful tool, but to solve this very problem I 
you could put your OOo files in a Daisy repository, manage the structure 
using their navigation editor and use Forrest to render it like all 
other content, thus you extend the functionality of Daisy without 
duplicating any development effort.

Having said that, I would not object to a contribution like the one you 
suggest. I'm just not sure how current devs would contribute. This has 
come up many times in the past, so far noone has felt a strong enough 
itch, given there are other tools that solve the problem. Of course, 
things change and there are many new devs here now, please don't let me 
put you off, I am sure it would be a useful tool, if you have the itch, 
go scratch it ;-)

Your original suggestion of providing a system to automatically build 
the struture from the directory is a different issue, that can be done 
in just a few lines of code, but does, as you described earlier, have 
considerable drawbacks.


View raw message