[opencms] [opencms-dev] openCMS 6 beta 2 - Categorization of StructuredContent

[bart vandendriessche]

Thanks for the reply, a few remarks:
 From a user point of view, it is easier to be able to select a category 
when creating a specific content. It is in my opinion quite error prone 
to have to create a sibling of every type of content under the 
appropriate directory structure. This might be feasible for content that 
is not added very often, but for things like arcticles or newsposts, 
remembering to create a sibling in the appropriate folder is cumbersome. 
Also, imagine a content type that can belong to multiple categories, you 
would have to create a extra sibling for every category, leading to more 
confusion.

It might be more work initialy to try and make some sort of widget that 
would contain a list of available categories, but i'm quite sure in the 
long run it would pay off in terms of maintainability and flexibility. 
Also handling multiple categories would be easier to manage, there 
should only be some kind of validation that checks if a user selected 
the same category twice (or more).
The downside I see to working with a separate Structured Content for 
every type of category, is that you would have to have one path were you 
hold them, and then hardcode this path into the widget (allthough it 
might be possible to deal with this through using properties on the 
original content xsd).

Best regards,
Bart Vandendriessche



Jorge González wrote:

>Well, this is not the best approach, but actually i'm using a folder tree
>with sibilings to categorize the xml content objects.
>
>So, there is a main content branch, containing the contents organized by a
>unique key, "location" for example.
>
>So we have a  (this is an example)
>/contents/place/world/europe/france/paris.xml content
>
>And sibilings to this content
>/categories/cities/paris.xml --> .../france/paris.xml
>
>Well, an easy shot.
>
>This kind of tree is good enought for navigation, but terrible for checking
>"which categories has "paris".
>
>This is one of the reasons for inventing "relational" databases and one of
>the real problems of "plain xml file database" persistence used in ocms.
>
>So, my final though:
>
>This is the content flow used (afaik) in ocms
>
>Reading contents
>
>(1)DATABASE (relational)  ---(2)--->  (3) XML   ----(4)---->   HTML
>
>1. The database store xml files, plain text strings
>2. The contents are recovered (plain)
>3. The xml file is the real content model we want to think about.
>4. The xml is transformed (various ways) into html, this is the 'view' part
>of the flow.
>
>Well, we have a problem in (3) because we want relationships, and we only
>have plain files. We could build a relationship system on the xml layer, but
>we are working on plain files database, and that's very slow isn't it ?
>
>Why don't we use the relational database ? (probably too complex, i
>guess...)
>
>
>
>
>_______________________________________________
>This mail is send to you from the opencms-dev mailing list
>To change your list options, or to unsubscribe from the list, please visit
>http://mail.opencms.org/mailman/listinfo/opencms-dev
>
>  
>