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