forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Where is the line between Forrest and a CMS
Date Tue, 08 Nov 2005 01:40:22 GMT
Ross Gardler wrote:
> 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.

In the past we have said that Forrest is not concerned
about editing of source documents, including document
content, and forrest configuration files. Use any text
editor or xml editor.

Forrest's job is to draw the content together, add other
nuggets of information, structure it all, and apply the

We would rather integrate with proper content management
systems, than try to do that as well.

The editing of Forrest-specific configuration files is a
different matter. As said above, people can use normal
editors for that. The idea sounds good to utilise Cocoon Forms
to make it a specialised part of the Forrest webapp mode.
However i reckon that we need to limit that to our
configuration files. My view is that we should not go
beyond that scope.

> 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 has multiple purposes: Navigation, link abstraction and
management, table of contents.

> 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 see Forrest as far more than an output module,
and agree that various CMS input modules is the
way to go.


> >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.
> Ross

View raw message