Ross Gardler wrote:
hepabolu wrote:
Arje Cahn wrote:
Yes, create a doc typoe, add a few relevant fields (including one of
tags.
Helma, do you know how to do this? If you add the type, I'll start
converting the sites..
Arje
I created a CocoonLiveSiteDocument (check spelling!) with a simple
content part and a Metadata part that should behave like the Book
Metadata part. However, it doesn't. I suppose Bruno has added some
extra processing underneath that I should have a look into, but
somehow I can't get onto the server to have a look.
So for now there is not much else I can do.
<thinking out loud>
I think, to make things future-proof, we need a flexible metadata
part, much like the bookmetadata part, where metadata key/value pairs
can be added, rather than a set number of fields which accommodate for
the current distinctions (category and version).
The approach I use here for our documentation system is to have a
multi-valued field that any user can use to tag a document. I also have
a set of collections that are the "official" classifications.
Right, but then you have a predefined selection list with available
values for the field.
If you think otherwise, I'd be happy to create two fields, one with a
selection list for the versions and one with a selection list for the
categories.
Do you mean Cocoon version? Should this be a document variant? So you
would have a single live sites document, with X variants, one for each
major version.
No, I think using branches for this would be misusing the intention of
branches/variants.
IMO branches/variants are much like SVN branches: in our case: document
X describes a Cocoon feature that is relevant to Cocoon version 2.1.Y.
If this feature changes in 2.2 the document would get a branch/variant
which contains the updated documentation for version 2.2. So for both
2.1.Y and 2.2 document X exists but has different content.
What we are talking about for the Live Sites is a _TAG_ that identifies
the Cocoon version the site was developed with and a seperate TAG that
identifies a category it falls into. This document does not describe a
feature of Cocoon, but rather an example of a specific version. It will
therefore not change when a new Cocoon release comes out, but only when
the creator indicates he/she has used a different Cocoon version.
What I was thinking about initially was having two fields with free-text
entry. That would make the setup easy, but we run the risk of a data
entry variation.
A variation is the way Bruno set up the BookMetaData where you can enter
XML as key/value pairs, but I haven't been able to figure out yet how
that was done.
I just created a LiveSiteCocoonversion field and added all current
versions to the selection list. I also created a free-text
LiveSiteCategory field. For now there are no predefined categories, but
given some discussion they will surface. ;-)
Note: I think "category" should allow multiple values. If this means the
selection list contains various "sets" (e.g. '..is used for/by', 'size
of website', 'prominent features of Cocoon used'), I'm ok with that. I'd
rather keep it simple at first.
I'll try rewriting one page (2.1.7) later if time permits, to see if it
works out as planned. If others beat me to it, that's fine. ;-)
Bye, Helma
- Re: [docs] Livesites by working area hepabolu
-
