I posted this message to mailman-users, and then the more I was thinking about it, the more I began to think this was a question for developers. Please tell me what you think:
I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with the Subscribe Results Page (/mailman/subscribe/listname). More specifically, I have edited the HTML and whenever I view the page, mailman appears to be prepending the following to the source:
<HTML> <HEAD> </HEAD> <BODY <BODY bgcolor="#ffffff">
which I'm sure you can imagine is wreaking havoc on the rest of my HTML. Has anyone else had this problem, or is this fixed in future releases? Since I am not an admin on the server I am configuring it will be difficult (Redhat installs mailman in /var/mailman) to recompile mailman.
I have just checked http://mail.python.org/mailman/subscribe/mailman-users and you can see for yourself that this is also happening with the version of mailman that serves this list.
- jim dinan.
James Dinan james@gilbertwalker.com Gilbert Walker Group: Lenox, MA U.S.A Available: http://www.gilbertwalker.com
On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:
I posted this message to mailman-users, and then the more I was thinking about it, the more I began to think this was a question for developers. Please tell me what you think:
I am running Mailman 2.0.1 on Redhat 6.2 and I am having difficulty with the Subscribe Results Page (/mailman/subscribe/listname). More specifically, I have edited the HTML and whenever I view the page, mailman appears to be prepending the following to the source:
<HTML> <HEAD> </HEAD> <BODY <BODY bgcolor="#ffffff">
Yes. This is an open bug, and an old one. It still requires a Pronouncement from Barry. The problem is that Mailman creates a HTMLgen Document instead of a HeadlessDocument, for the list page. From the top of my head the fix is to change
doc = Document()
into
doc = HeadlessDocument()
in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry is reluctant to fix it because of possible breakage (people might have made template files with the (Headfull)Document in mind.) Barry ? :)
- Thomas Wouters
| in Mailman/Cgi/listinfo.py, function listinfo_overview(). I believe Barry | is reluctant to fix it because of possible breakage (people might have made | template files with the (Headfull)Document in mind.) Barry ? :)
Actually, the fix is in htmlformat.py, around line 281:
output.append('%s</HEAD>' % tab)
output.append('%s<BODY' % tab)
quals = []
for k, v in kws.items():
quals.append('%s="%s"' % (k, v))
output.append('%s<BODY %s>' % (tab, string.join(quals, ' ')))
output.append(Container.Format(self, indent))
ok, first, we append '<body' to the output. then we run in a little loop, before we append another <body> with any arguments. I raised the problem on April 16th, and you told me about the headless problem, but just commenting out
output.append('%s<BODY' % tab)
has worked fine for me (and any users of Mailman on Debian).
"TW" == Thomas Wouters thomas@xs4all.net writes:
TW> On Mon, Jun 25, 2001 at 10:49:27AM -0700, James Dinan wrote:
TW> Yes. This is an open bug, and an old one. It still requires a
TW> Pronouncement from Barry. The problem is that Mailman creates
TW> a HTMLgen Document instead of a HeadlessDocument, for the list
TW> page. From the top of my head the fix is to change
TW> doc = Document()
TW> into
TW> doc = HeadlessDocument()
TW> in Mailman/Cgi/listinfo.py, function listinfo_overview(). I
TW> believe Barry is reluctant to fix it because of possible
TW> breakage (people might have made template files with the
TW> (Headfull)Document in mind.) Barry ? :)
Well, with MM2.1 I'm certainly less concerned about any theoretical breakages, especially since changing this will probably accomplish exactly the opposite! :)
"TFH" == Tollef Fog Heen tollef@add.no writes:
TFH> ok, first, we append '<body' to the output. then we run in a
TFH> little loop, before we append another <body> with any
TFH> arguments. I raised the problem on April 16th, and you told
TFH> me about the headless problem, but just commenting out
TFH> output.append('%s<BODY' % tab)
TFH> has worked fine for me (and any users of Mailman on Debian).
This is certainly one of the problems, which will affect any Document()-based web page. However, Thomas is also right that any page that is generated from a template (e.g. subscribe.html) either must not include the header stuff, or must use a HeadlessDocument(). Fixing this is going to take a bit of grunt work, especially if we want to allow the html templates to go either way.
Let's make our lives simple and say that any templated html file must include its own html armor (and thus will be HeadlessDocument() based), while all non-templated script-generated ones will be Document() based to get the standard header and footers.
If you agree, I can start fixing the web ui to conform to this rule.
The more I think about the web ui, the more certain I am that we need
api's so sites can supply any web ui they want, with adaptors for the Mailman "classic" ui.
Mailman's classic ui should be based on something like Zope's Presentation Templates (ZPT). My understanding is that these will /not/ require sucking in all of Zope (i.e. they can be used standalone), they are quite powerful, and allow for html editing to live nicely with script specialization. There's the little matter of ZPL/GPL incompatibility that's currently holding me back from investigating this avenue further.
-Barry
Let's make our lives simple and say that any templated html file must include its own html armor (and thus will be HeadlessDocument() based), while all non-templated script-generated ones will be Document() based to get the standard header and footers.
If you agree, I can start fixing the web ui to conform to this rule.
I certainly agree with that. In fact, right now I am in the process of hacking together a custom ui for MM2 which, I am surprised to find, is much harder than I imagined. One problem that I have is that somtimes funny things will happen inside the <MM-...> tags. Some tags leave white space after themselves, and I can't really control the presentation of the content inside of the tags (i.e. font, size, etc) directly, often I have to wrap them in a container.
I wonder if there might be some way to pull these <MM-...> tags out of the source and stick them into a library of some sort that you can sustomize for each list. I know this would probabbly mean quite a lot of work, but think of how cool that would be. ;) You could have the configuration program modify the text in the libraries for less advanced users and for more hardcore hackers they can edit the XML/HTML themselves.
If you're interested to see how far I've gotten, the mailing list I'm working on (for my summer job) is available at http://www.gilbertwalker.com/mailman/listinfo/advisorbits. Assuming I haven't broken it again it should still be up. But, you will notice that there are still many error messages which I cannot touch the HTML for. :/
Oh yeah, one other idea I had (this really pertains to my particular site architecture) is that it would be incredibly convenient to have a customizable page header and footer that could be called via an <MM-...> tag that you could wrap any sort of content in. Sort of like making HeadlessDocument() customizable I guess.
Thanks for all your help!
- jim.
James Dinan james@gilbertwalker.com Gilbert Walker Group: Lenox, MA U.S.A Available: http://www.gilbertwalker.com
This is certainly one of the problems, which will affect any Document()-based web page. However, Thomas is also right that any page that is generated from a template (e.g. subscribe.html) either must not include the header stuff, or must use a HeadlessDocument(). Fixing this is going to take a bit of grunt work, especially if we want to allow the html templates to go either way.
The more I think about the web ui, the more certain I am that we need
api's so sites can supply any web ui they want, with adaptors for the Mailman "classic" ui.
Mailman's classic ui should be based on something like Zope's Presentation Templates (ZPT). My understanding is that these will /not/ require sucking in all of Zope (i.e. they can be used standalone), they are quite powerful, and allow for html editing to live nicely with script specialization. There's the little matter of ZPL/GPL incompatibility that's currently holding me back from investigating this avenue further.
-Barry
"JD" == James Dinan james@gilbertwalker.com writes:
JD> One problem that I have is that somtimes funny things will
JD> happen inside the <MM-...> tags.
Have I mentioned how much I dislike the <mm-> tags? Or how much I reaaally hate having both those and normal Python %()s string substitutions? ;)
JD> If you're interested to see how far I've gotten, the mailing
JD> list I'm working on (for my summer job) is available at
JD> http://www.gilbertwalker.com/mailman/listinfo/advisorbits.
JD> Assuming I haven't broken it again it should still be up.
JD> But, you will notice that there are still many error messages
JD> which I cannot touch the HTML for. :/
I'll have to check this out when I get home. I don't have an easy way to do Javascript here.
JD> Oh yeah, one other idea I had (this really pertains to my
JD> particular site architecture) is that it would be incredibly
JD> convenient to have a customizable page header and footer that
JD> could be called via an <MM-...> tag that you could wrap any
JD> sort of content in. Sort of like making HeadlessDocument()
JD> customizable I guess.
I agree. At this point though, I just want to get the basics of the web ui fixed. I don't think I'll have the cycles to completely revamp the whole thing.
-Barry
participants (4)
-
barry＠digicool.com -
James Dinan -
Thomas Wouters -
Tollef Fog Heen