Some of the other people here at cnri are using mailman, and they've hit up against one small change needed. I thought i'd mention it here, in case anyone gets the chance and inclination to address it. I also have one other item which i would really like to do, but the eventuality of actually doing it may be less near than i'd like (especially since i'm going away for a week, and there's all that catch-up time on return).
The first item is the ability to edit the new-member welcome message. We offer list managers the ability to edit the html pages, and they get to see the way the magic refs (eg, <MM-List-Name>) are used on the template to see how they could use them for their own versions. Well, there is a number of standard mail messages, including particularly the welcome message, that they may want to edit. (IN FACT, two different groups, separately, came to me today with the need to edit the welcome message - for different reasons! A sure sign...)
I think we would have to change the format substitutions, currently all the "%s" order dependent style, to be "%(real_name)s" dictionary substitutions, and otherwise do the same kind of thing we do for the html templates. (Ah, i see barry's done that in some recent checkins.) There is a bunch of messages, some which may benefit from this treatment, other might just clutter the list admins choices.
Along these lines, there's something much more encompassing i'd like to do or see done. I'd like to extend the handling of list admin options and html templates so list-specific versions are only squirreled away in list-specific space if and when the list admin changes them from the default. This way, the central administrator could change the template or default values, and the new value would show for all the lists that haven't tailored their own versions. This would certainly be suitable for something like the html pages, where site style changes need propagation, and also for stuff like the forbidden posters. It may not be suitable for some others.
This should be easy for the template files - just don't stash list-specific copies until an edit is made (and the edited copy differs), and use the default template if no list-specific one exists. It'd also be good to offer a way in the edit interface to revert to the default version, wiping out the list-specific copy.
For the list admin options, we'd need a new field in the options data structure specifying the *name* of the default value, and likewise some way for the gui option for the list admin to explicitly revert to the default. Maybe there should be some way to have a locked-in list-specific setting, even if it doesn't differ from the _current_ site default. And then all the routines that use the list admin options will have to mediate through a routine (or options mediator object) that takes the name of the option and gets the default value when suitable...
Well, i hope this is at least slightly understandable, if quick - i gotta run. C ya later!
Ken
On Thu, 28 May 1998, Ken Manheimer wrote:
Some of the other people here at cnri are using mailman, and they've hit up against one small change needed. I thought i'd mention it here, in case anyone gets the chance and inclination to address it. I also have one other item which i would really like to do, but the eventuality of actually doing it may be less near than i'd like (especially since i'm going away for a week, and there's all that catch-up time on return).
The first item is the ability to edit the new-member welcome message. We offer list managers the ability to edit the html pages, and they get to see the way the magic refs (eg, <MM-List-Name>) are used on the template to see how they could use them for their own versions. Well, there is a number of standard mail messages, including particularly the welcome message, that they may want to edit. (IN FACT, two different groups, separately, came to me today with the need to edit the welcome message - for different reasons! A sure sign...)
I think we would have to change the format substitutions, currently all the "%s" order dependent style, to be "%(real_name)s" dictionary substitutions, and otherwise do the same kind of thing we do for the html templates. (Ah, i see barry's done that in some recent checkins.) There is a bunch of messages, some which may benefit from this treatment, other might just clutter the list admins choices.
Hmm.. Has anyone looked at doing the whole shot with Digicool'sDocumentTemplate modules? The do both html and text, and their DTML is alot more flexible than mailan's current 'magic-tag' system. It seems a natural.
Along these lines, there's something much more encompassing i'd like to do or see done. I'd like to extend the handling of list admin options and html templates so list-specific versions are only squirreled away in list-specific space if and when the list admin changes them from the default. This way, the central administrator could change the template or default values, and the new value would show for all the lists that haven't tailored their own versions. This would certainly be suitable for something like the html pages, where site style changes need propagation, and also for stuff like the forbidden posters. It may not be suitable for some others.
This should be easy for the template files - just don't stash list-specific copies until an edit is made (and the edited copy differs), and use the default template if no list-specific one exists. It'd also be good to offer a way in the edit interface to revert to the default version, wiping out the list-specific copy.
For the list admin options, we'd need a new field in the options data structure specifying the *name* of the default value, and likewise some way for the gui option for the list admin to explicitly revert to the default. Maybe there should be some way to have a locked-in list-specific setting, even if it doesn't differ from the _current_ site default. And then all the routines that use the list admin options will have to mediate through a routine (or options mediator object) that takes the name of the option and gets the default value when suitable...
Hmm... Suggestion... In my UserDB module (which I' not abandoningfor various other reasons) that stored a database of User objects for each list, I had something like this. The Mailinglist object held certain 'default' settings for users, and the User object contained oly those settings that were changed. the User objects used the Aquisition mdule (part of the Extention Class system) to fetch the info from the list object if they didn't have it.
IMHO, I realy think mailman needs a class of persistant Serverobject (one for each virtual server) to store server-specific info which really dosen't belong in the mailinglist object. Such an object could store defaults in the same way as my UserDB did . It could also have methods for things like getting the list of lists.
PS Anyone thought of using mailman with Bobo?
-The Dragon De Monsyne
On Thu, May 28, 1998 at 09:06:15PM -0500, The Dragon De Monsyne wrote:
Hmm.. Has anyone looked at doing the whole shot with Digicool's DocumentTemplate modules? The do both html and text, and their DTML is alot more flexible than mailan's current 'magic-tag' system. It seems a natural.
Sounds good. I don't think anyone is persuing that right now, if you want to do it..
IMHO, I realy think mailman needs a class of persistant Server object (one for each virtual server) to store server-specific info which really dosen't belong in the mailinglist object. Such an object could store defaults in the same way as my UserDB did . It could also have methods for things like getting the list of lists.
Hmm, on one level it does belong in the mailing list object. For example, you might have the default set up to be: www.mymachine.com for both web stuff and list stuff, and someone might want to change it to be www.mymachine.com for the web page, and list.mymachine.com for the list. Or the other way around. I've seen a few lists use completely different domain names for the mail address and the web address. It's definitely a property of the list, although storing defaults on a per-server level would be good. I think I'd prioritize it fairly low, though, since creating new lists is not a frequently done thing. If you want to work on it, though, I do think it'd be a fine addition.
Catching up on some issues...
"KM" == Ken Manheimer klm@python.org writes:
KM> The first item is the ability to edit the new-member welcome
KM> message.[...]
KM> I think we would have to change the format substitutions,
KM> currently all the "%s" order dependent style, to be
KM> "%(real_name)s" dictionary substitutions, and otherwise do the
KM> same kind of thing we do for the html templates. (Ah, i see
KM> barry's done that in some recent checkins.) There is a bunch
KM> of messages, some which may benefit from this treatment, other
KM> might just clutter the list admins choices.Dragon subsequently mentioned Digicool's DocumentTemplate stuff, and that might certainly be a long-term goal. One of the short term things I'd like to do is to move most of the triple-quoted-strings of text that serve as templates, out of the .py files, and into text file in say, $prefix/data. Then convert them to using dictionary interpolation of values. I think this will help move us in a direction of being able to do things perhaps like I18N, using DocumentTemplate (perhaps), etc. It'll certainly make it easier to track down and change various publically visible texts.
-Barry
participants (4)
-
Barry A. Warsaw -
John Viega -
Ken Manheimer -
The Dragon De Monsyne