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

[sgomez at soluziona.com]

Hi,

I "solved" this issue by defining Boolean attributes in my XmlContent
Definition
mapped to a new property of the resource.

This is useful when you have several "types" of xmlcontent. They are
different
not by their "definition"(all of them have the same attributes),
but by the content itself, and when the categorization and the content
itself
may dynamically change(inside pre-defined categories).

I also have thought in Jorge's solution, but with contents like news, etc.,
where the categorization of a given content may be changed by an editor at
anytime, I would not know which is the best moment to create/delete
the siblings, specially without modifying the OpenCms's editor code to
create the
siblings when saving the xmlcontent.

By the way, Jorge, do you create the siblings by code or at the workplace
directly? In
which moment?

With this "solution" I define news properties(mappings of an xml-element)
for
the resource, so that it is not necessary to read the whole file(to search
for the xml-element of the category) to know if a content belongs to a
given
category. Also you avoid to create/delete new siblings when the
categorization
changes, and you can easily know which categories a content belongs to,
just
reading the corresponding properties.

The main drawback is that you have to define the categories BEFORE you
define
your XmlContent-type as each category has an attribute in the XmlContent
associated, and since the list of contents of a given category is
dynamically
generated by reading the resource properties, I have not checked if the
performance
may slow down.(I will tell  you,...)

Regards,
Silvia Gómez



>----------------------------------
>Message: 7
>Date: Tue, 12 Apr 2005 14:29:51 +0200
>From: bart vandendriessche <bart at nascom.be>
>Subject: Re: [opencms] [opencms-dev] openCMS 6 beta 2 - Categorization
>of   StructuredContent
>To: The OpenCms mailing list <opencms-dev at opencms.org>
>Message-ID: <425BBF3F.3050406 at nascom.be>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>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
>>
>>
>>