At Sat, 11 Dec 1999 12:40:55 +0100, Emile Heyns <[EMAIL PROTECTED]> wrote:
>
>Paul Newby wrote:
>> Really what you have in the articles is two types of
>> information: > 'content,' with components that are closely
>> bound and are relatively isolated from anything external;
>> and then apart from content some kind of 'package', consisting
>> of components that are configured to arrange and express the article
>> content in the environment in which it's referenced.
>>
>> This suggests that article_content might be disconnected
>> from topics altogether, and then joined with (at least one)
>> article_package, of which there may be many versions
>> registered under different topics, but all referencing the
>> same article_content.
>
>This could work, and would in fact be a very clean approach. It
>does however bring a few challenges:
>
>* Where does ACL checking cascade to when no explicit ACL is set on
>the article? The current setup would enable a site maintainer to
>grant ownership of a topic tree to a group of persons who could
>then take full control over the tree. When the article contents
>is no longer explicitly part of a specific topic tree you cannot
>maintain this approach. It would also effectively make the article
>space flat, which is going to make maintenance harder.
We have two sets of data: content and display data. So.... why not let content
have one set of permissions and display another?
That way, you could have a group of people in charge of the content, and
another in charge of the formatting/display...
for instance, say you had a major news agency. You want to provide an east
coast and west coast version of the news... (for whatever reason, perhaps
much like the RadioDigest site)... So, you have a metatree where the different
reporters have seperate topics, which they have full access...
Then, the west coast and east coast sites, simply edit their own content
trees, which they have full access to, to point to those articles which
they see fit to include.
In addition, topics in the content trees should be able to point to topics
in the metatrees. (specifying some set of default display data). That way,
for a simple site, you'd simply set the defaults on a "root" topic pointing
to the root of the metatree. In addition, you could overide the defaults
by normally including the topic.
Ie, if you had a topic FOO, which pointed to metatopic FOOa, then you could
place an article, BAR, which pointed to BARa (an article of FOOa), which
would ovveride FOO's settings.
>* What to do with orphaned articles? You can't unlink them after
>the last link is gone, since some other editor might want it, and
>besides, ownership of the links will have no relationship to
>ownership of the content.
Hmm.. this is a larger problem. I suppose that you could keep track of the
last access time, and flag anything that is A) unlinked and B) not accessed
within X, a user defined time... (by flagging, I mean e-mailing the webmaster/owners
or having a notice at the root of the admin site... Something like this.)
That way, if people wanted to keep it, they could. Also, it'd be wonderful
if there was some way to archive portions of a site... possibly with the
option to import it to a -different- site than it was exported from?
>* (minor) list fetches would require a SQL join, thereby making
>the _fast routines not.
Ah.... this I do not understand, unfortunately. Even so:
To speed up searches + such, some caching information could be put into
the pointer topic/article - the fields could double as the "override" fields.
Ie, if you need to overide the title, then you simply modify the cached-
title field
>
>
>Ben Garney wrote:
>> To restate:
>>
>> Two sets of data:
>> o Meta Data
>> - one
>> - contains an "article/topic" hierarchy
>> - consists of solely "content" data - ie, the author,
>> abstract, content fields, as well as some
>> "meta-data" -- internal comments, flags, etc. not
>> relating to display...
>>
>> o Site Map(s)
>> - more than one, such as when you have more than one site.
>> - contains an "article/topic" hierarchy
>> - articles...
>> - reference an article from the MetaData tree.
>> - contain display data (format, location in site, related articles
>> on site, etc.)
>> - topics....
>> - may either be created from scratch or reference a topic from
>> the MetaData tree
>> - contain display data, descriptions, etc.
>> - optional "override" ability - ie, to override an abstract which
>> doesn't quite fit, or trim titles, or the like. (may just be
>> option to load alternate abstract from the MetaData tree.)
>>
>> How's this sound?
>
>This would be a pretty clean solution, but it does mean that you would
>have to
>do double work for simple sites, since basically every content tree
>would
>have to be populated with links. Also, to link topic trees you would
With topic level linking, this would be less of an issue.
>have to
>cross-link into a sitemap (iso into the meta tree) since the metatree
>will
>have no display data. And I can see situations where you want multiple
>non-related content trees.
Multiple non-related content trees = multiple non-related subtrees in metatree.
>
>I think adding some kind of dumb-but-rich links to articles and topics
>is
>the best compromise. You can still set apart a content tree to be the
>meta
>tree; just set up a second (third, fourth,...) content tree that has
>only
>links to your meta tree.
Perhaps... :)
>
>Bye,
>Emile
>
IMPORTANT NOTICE: If you are not using HushMail, this message could have been
read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
