Paul Newby wrote:
> Making the linking articles clones of the target sounds attractive, but
> sometimes you might want to set some of the fields of the linking and
> target articles independently. For example, you could set the score of
> the linking article so that it can be sorted in a way that makes sense
> in another context.
Hadn't thought of that. Makes sense. In that case, the symlink table is
out.
Is built-in symlinks something that y'all see as valuable, BTW? Rather
than symlinks implemented in PHP (the 2.0 extendable record structure
can do this quite cleanly).
> I don't think it presents too much of a management problem to oblige the
> user to set these fields up manually (to be either the same as the target
> or different),
But these fields are not fixed in time. I think it would present
somewhat
of a management problem to oblige the user to keep track of the target
and
keep updating the link fields.
> in which case the Midgard functions would only have to ignore
> the fields in the linking article that haven't been set.
The Midgard sorting is actually straight SQL sorting, which has no
concept
of "ignore when not set".
> It might be nice to have a utility to clone the fields used for sorting that the
> person setting up the linking article can use them as defaults.
That would be easy, of course.
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]
