I've been posting a big pile of patches on the Sourceforge repository. I think they're mostly stable now. They're largely cosmetic, so in case anyone wants to look at the results, please check out
http://listtest.uchicago.edu/The "dgctest1" list's archives are public, and completely uninteresting. I'm using the built-in pipermail for now. I'll probably change that in a few weeks to MHonArc. But first, I'll post more patches to drive the pipermail HTML into compliance with the rest of the pages, just to be thorough about it.
All the customization on the site is done it mm_cfg.py or in the templates files. I've attached my mm_cfg.py so you can see the config parameters I've altered. With the default mm_cfg.py and templates, the whole thing looks identical to the current default mailman installation.
In particular, one of my patches converts all the hard-coded HTML in listinfo.py and admin.py into templates. The "tone" of the document on this server is governed in mm_cfg, but the textual content, the "shortcuts" box, etc are in the template. These are configuration options I learned to want with our 1.0 installation.
OK, just wanted this to be out there so people can see what I'm hoping for -- maybe it'll be helpful in deciding whether to incorporate the patches. Any thoughts? I probably should not go into production with this if there's strong sentiment against it.
-- -D. dgc@uchicago.edu NSIT University of Chicago
At 11:22 PM -0500 9/7/00, David Champion wrote:
In particular, one of my patches converts all the hard-coded HTML in listinfo.py and admin.py into templates.
neat!
Today, out of need, I was hacking in standard header/footer entries across mailman. it's (mostly) working, but not ready to submit to sourceforge yet. but this stuff really needs some cleanup. I have some ideas, but no time to implement them yet..
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"
On 2000.09.07, in <p04320402b5de1ad6ffdb@[209.239.169.197]>, "Chuq Von Rospach" <chuqui@plaidworks.com> wrote:
Today, out of need, I was hacking in standard header/footer entries across mailman. it's (mostly) working, but not ready to submit to sourceforge yet. but this stuff really needs some cleanup. I have some ideas, but no time to implement them yet..
Yeah, what you see on my server has that, too. Want to look at patch 101383? Maybe there's some useful integration to be done.
http://sourceforge.net/patch/?func=detailpatch&patch_id=101383&group_id=103
-- -D. dgc@uchicago.edu NSIT University of Chicago
At 11:36 PM -0500 9/7/00, David Champion wrote:
Yeah, what you see on my server has that, too. Want to look at patch 101383? Maybe there's some useful integration to be done.
http://sourceforge.net/patch/?func=detailpatch&patch_id=101383&group_id=103
Nice. Cleaner than my hack. I think I'll go back-patch this into my hack tomorrow.
one quick thought: if GLOBAL_HEADER and GLOBAL_FOOTER are paths to files, include the content of the files....
I may try that tomorrow.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"
On 2000.09.07, in <p04320405b5de1e12c264@[209.239.169.197]>, "Chuq Von Rospach" <chuqui@plaidworks.com> wrote:
one quick thought: if GLOBAL_HEADER and GLOBAL_FOOTER are paths to files, include the content of the files....
I may try that tomorrow.
That's a good idea. Currently I'm concatenating it with other variables, like the color values that I created in another patch, or the value of MAILMAN_OWNER, etc. It should be done with Utils.maketext(), I guess. But offhand, I don't know whether the values in mm_cfg are automatically part of any available dictionary. If so, that's quite convenient.
I'll be very interested in anything you come up with.
-- -D. dgc@uchicago.edu NSIT University of Chicago
At 11:49 PM -0500 9/7/00, David Champion wrote:
I'll be very interested in anything you come up with.
Basically, I plan on splitting content out from mailman completely on a functional basis, and derive it through an API. The API is basically defined as "GetThing(thing, list, language)", which returns a hunk 'o text.
Now, "thing" is any hunk of text, for instance, "unsubscribe_message" or "listinfo_page". A certain set of these would have to be defined as standard entry points, and can include other things. embedded things are expanded within GetThing, so the mailman program doesn't even need to think about it.
Now, behind the scenes, it can get funky, since many of these things are configurable on a list-specific or global basis, some are meta-things based on system config or state, etc. But conceptually, I want to pull out all of the messaging content from the rest of mailman, because it makes it (a) infinitely easier to administer, change and user, (b) cuts the complexity of the code completely, (c) makes stuffing it in a database for management trivial (and database independent, in theory), and (d) you basically get multi-language support for free (well, in theory) because you can define parallel sets of content in each language, and let the end-user define which their preferred language is.
It needs some fleshing out, but that's the 10,000 foot level. it'd need an administrative interface in the API, and databasing in the back-end, and administrative controls such that the site admin can lock down some values so that a list-administrator can't change them, something not currently possible with Mailman.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"
participants (2)
-
Chuq Von Rospach -
David Champion