templating, search, and stuff...
I've manually dug through one too many pipermail archives, so I've decided it's time to help fix the problem by connecting a search index to mailman/pipermail. I'm probably going to use mifluz (after I swig a python wrapper for it). If anyone has this in progress or wants to coordinate on it, drop me a note.
Also, in fishing through the TODO list, I notice that adding some kind of templating system is still on there. I want to point [whomever] at a really easy to use and fast templating system called Clearsilver. It's a open-source cousin to the template system we used at eGroups.com and is still used for Yahoo Groups, and it's 'really great'. I'd love to convert Mailman over myself, but I'm quite sure I won't find the time. If someone wants to put work into this, I'm happy to help with some tech support and examples. Of course it already has a Python wrapper, as much of eGroups.com (and some of Yahoo Groups) is written in Python.
-- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net
"DJ" == David Jeske <jeske@chat.net> writes:
DJ> Also, in fishing through the TODO list, I notice that adding
DJ> some kind of templating system is still on there.Improving the templating system (for MM3) is more than just picking one and going with it. The real issue is that folks want to put all kinds of web skins on Mailman, to integrate them into their own way of managing their sites. Some people don't care about the integration, and for them we can pick a Good One and use that as the default. But they've got to be able to chuck it, design their own web interface, and integrate it easily into Mailman. For that we need APIs, a clean architecture, and component-like system.
-Barry
Improving the templating system (for MM3) is more than just picking one and going with it. The real issue is that folks want to put all kinds of web skins on Mailman, to integrate them into their own way of managing their sites. Some people don't care about the integration, and for them we can pick a Good One and use that as the default. But they've got to be able to chuck it, design their own web interface, and integrate it easily into Mailman. For that we need APIs, a clean architecture, and component-like system.
I'd suggest to look at what phpGroupWare is doing and be as compatible with that as possible.
Greetings, Norbert.
-- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com
On Fri, Apr 05, 2002 at 10:19:09AM -0500, Barry A. Warsaw wrote:
"DJ" == David Jeske <jeske@chat.net> writes:
DJ> Also, in fishing through the TODO list, I notice that adding DJ> some kind of templating system is still on there.Improving the templating system (for MM3) is more than just picking one and going with it. The real issue is that folks want to put all kinds of web skins on Mailman, to integrate them into their own way of managing their sites.
First off, it's no skin off my back, I don't run or administer mailman, I just interact with them on several mailing lists so I'm happy to help out.
However, if you look at Clearsilver, you'll find that it was designed to handle exactly this kind of skinning. We used it for cobranding and OEM deals back at eGroups. While integrating into Yahoo, we ran the old eGroups version of the UI in Japanese for six months while running every other language in the new "Yahoo UI", on the same codebase. It really excels at this. The majority of the "skinning" of the UI to the Yahoo look and feel took one engineer less than 10 days.
Some people don't care about the integration, and for them we can pick a Good One and use that as the default. But they've got to be able to chuck it, design their own web interface, and integrate it easily into Mailman. For that we need APIs, a clean architecture, and component-like system.
If you read my paper on "dataset driven templating", you'll find that this is exactly what Clearsilver provides, in an extremely fast and easy to use package. There are other template systems that do this also, but for integrating with Python, Clearsilver is the fastest and most mature way to go.
http://www.clearsilver.net/docs/apples_to_oranges.hdf http://www.clearsilver.net/docs/man_templates.hdf
The "dataset" (like a simpler form of XML) is your API. It sits between the application logic and the page template, and allows you to easily skin the application.
There are some advantages to using XML/XSLT instead, namely because you can write an XML schema and typecheck the XML output. However, considering Mailman is written in Python, I figure you all understand the development ease gained by using an untyped system over a typed one for small-ish projects like this.
Anyhow, I'm not here to get into an off-topic templating thread. I just saw that Mailman still didn't have templates and I figured I'd offer up some assistance.
-- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net
On Fri, 5 Apr 2002 10:19:09 -0500 Barry A Warsaw <barry@zope.com> wrote:
"DJ" == David Jeske <jeske@chat.net> writes:
DJ> Also, in fishing through the TODO list, I notice that adding some DJ> kind of templating system is still on there.
Improving the templating system (for MM3) is more than just picking one and going with it. The real issue is that folks want to put all kinds of web skins on Mailman, to integrate them into their own way of managing their sites.
More simply: Many of us want to integrate Mailman as a dynamic component into other dynamically generated web pages. just adding template support is good, but doesn't solve the base problem of enabling mailman to be a well behaved component in a web page that's otherwise assembled.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> More simply: Many of us want to integrate Mailman as a
JCL> dynamic component into other dynamically generated web pages.
JCL> just adding template support is good, but doesn't solve the
JCL> base problem of enabling mailman to be a well behaved
JCL> component in a web page that's otherwise assembled.Nicely said. -Barry
On 4/6/02 7:52 AM, "Barry A. Warsaw" <barry@zope.com> wrote:
JCL> just adding template support is good, but doesn't solve the JCL> base problem of enabling mailman to be a well behaved JCL> component in a web page that's otherwise assembled.
Nicely said.
Thinking about it, here's how I'd do this (at first glance)
Define two new variables:
MAILMAN_HEADER
MAILMAN_FOOTER
You can point these two one of two things: a file, or a function. If defined, the header replaces what Mailman normally spits out from <HTML> to <BODY>. The footer replaces </BODY> through </HTML> inclusive. This allows you to "box" the mailman content inside your site's interface (and FWIW, if you look at what I've done on www.lists.apple.com, that's exactly what I have done, only using mod_layout to do the boxing. It's also the way pages like applenews.lists.apple.com/unsubscribe work, since marketing controls the content and I control the cgi aspects, we built the pages to allow each side to manage their part independently. As long as we both behave, of course...)
If you have a simple interface, that's all you need. But if you have a more complex one, that¹s' where the function comes in. If you define these as functions, then those functions need to be in the python include path, but once you do that, you can do literally anything (suck the html out of a database, write it on the fly, whatever). The function is called with a single parameter that is one of a pre-defined set of constants that define which page is being rendered, so those functions have the ability to adapt the output to each page. The functions return a glop of text that is the HTML to be output.
This would allow mailman to adapt easily to ANY templating system, while being tied to none. Even the most complex interface system comes down to writing two python functions to interface to mailman. In most cases, the template files will be enough, but for big, complex sites the functionality is there as well.
And even better -- it's quite easy to implement inside mailman. It's a pretty trivial setup. And if you don't define those variables, mailman continues to work as it does now, so there are no upgrade/compatibility issues, either.
I'd guess this is 100 lines of python code, maybe less.
Thoughts?
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/
Stress is when you wake up screaming and you realize you haven't fallen asleep yet.
I've done enough custom hacking in my most important live 2.0.X install that I always wind up having to install patches by hand to ensure that nothing bad happens. This is fine, and I've no complaints (hey--what other software this great lets you modify it so thoroughly and easily?).
My complaint is that as often as not, during this manual patch process I wind up screwing up the indentation levels (which we all know in python effects the block structure) strictly because tabs are invisible. (Then cron barfs on me once a minute until I get it fixed--I realize there's no cron in 2.1, but that's not the issue--the fact that I broke it at all is the issue.)
I think the reason I had so many such troubles this past update was due to vim for some reason deciding to use tab=4 instead of tab=8 when displaying stuff to me.
I was hoping it would be a reasonable request to replace all tabs in the 2.1 code base with spaces to avoid this problem in the future?
What do y'all think?
(I hope I didn't just start a religious war...)
-Dale
participants (6)
-
barry＠zope.com -
Chuq Von Rospach -
Dale Newfield -
David Jeske -
J C Lawrence -
Norbert Bollow