cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hepabolu <hepab...@gmail.com>
Subject Re: [docs] Livesites by working area
Date Wed, 02 Nov 2005 09:13:33 GMT
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

Mime
View raw message