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.
* 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.
* (minor) list fetches would require a SQL join, thereby making
the _fast routines not.
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
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.
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.
Bye,
Emile
--
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]
