[prev] [thread] [next] [lurker] [Date index for 2002/08/31]
I want to start hacking in config so I want to discuss some of the
issues with youse two ...
For the purposes of clarity I'll use a plugin as example (in this
case the ReplyTo plugin) ...
There are two different types of config needed ...
per list (this list doesn't have reply to munging)
per user per list (but not on this list)
we could have a per user configuration as well which would override per
list but could be overridden by per user per list.
so I propose that the plugin interface changes so that it expects
process ($message, $user)
and can then work out whether it's been called as a per list
configuration or not.
then the plugin goes
sub process
{
# get the entities involved
my $message = shift;
my $list = $message->list;
my $user = shift;
# get the config
my $munge = undef;
# this automatically checks to see if there's a
# per_user or per_user_per_list config defined
$munge = $user->get_config($list, 'replyto_munge');
# if there isn't then get the list config
$munge = $list->get_config('replyto_munge')
unless (defined $munge);
# Erk, revert to default
$munge = $DEFAULT;
return $mail->head->replace('Reply-To', $mail->list->post_address)
if $munge;
}
which isn't exactly tricky.
Two thoughts arise from that
1. currently we've got a mix of passing around list/user ids and
list/user objects. Which do we want to standardize on? I'd suggest
objects.
2. Namespaces in configs. The example above just prefixes everything by
reply_to but it could be possible for the config methods to
automatically prepend a name space based on the caller's package.
so that would become
$munge = $list->get_config('munge');
which would silently be called in the list object as
$munge = $list_config->get($self->id, 'ReplyTo', 'munge');
Thoughts?
Simon
--
: third time's a charm
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52