Since Barry suggested that conversation about improving the mailman GUI should be moved here, I thought I'd take a minute to ask a couple starter questions.
First, let me say, that I'm willing to do some of the work on this part of the project. In the organization I work for (and run mailman for) the biggest complaints I hear revolve around the interface, and the lack of control over the design, so I'd love to see a proper template system in place.
That said, I'm not clear where this project stands. I've been reviewed the summary from last summer's SoC work, and while that's given me some idea of what was done, I don't have a good sense of how and where to get started on helping. Can you all offer some suggestions about what I can do to be helpful and contribute?
Aaron
I would also like to lend a hand wherever it is desired as well as offer some suggestions to help with the improvement of the Mailman user interface. Having watched the mailing lists since last November for news about improvements in the user interface and the template system, it was not really surprising that the subject came up again. Bryan has done some excellent work on version 2.1.7 as far as XHTML compliance.
Unfortunately there are a number of package related versions that cannot be upgraded easily because the packagers have not brought the RPMs up to date with the current stable release of Mailman (2.1.9). They may have reasons for this, including versions of Python that are supported in various packages as well as their own development cycles and lack of manpower. If I am not mistaken, RHEL3, and CentOS3 are still relegated to Mailman 2.1.5 due to a reliance on an earlier version of Python (again the packagers have not upgraded the RPMs). I have at least two machines that I would like to bring to Mailman 2.1.9, but it would do more harm than good and other factors prevent OS upgrades.
Areas where I can help include HTML/CSS/XHTML compliant markup for the user interface templates, extending generic classes into Python coding for inclusion in generic template styles, and perhaps even some built in help hints for the user interface (as part of the templates or Python coding).
My desired hopes would include Mailman 2.1.9 support for Python 2.2.3 without patches or changes to Python coding (for users of RHEL3 and CentOS3); Support for a single CSS file to change the look of any single virtual hosted mailing list; customizable administration pages as well as the user pages for a mailing list; full language support integrated throughout the templates; and finally, support for any template / user interface improvements for the current stable release of Mailman (2.1.9).
I am in full agreement with Aaron as far as the template system and look forward to further discussion on this topic.
Best regards,
Jon Reese
Aaron Crosman wrote:
Since Barry suggested that conversation about improving the mailman GUI should be moved here, I thought I'd take a minute to ask a couple starter questions.
First, let me say, that I'm willing to do some of the work on this part of the project. In the organization I work for (and run mailman for) the biggest complaints I hear revolve around the interface, and the lack of control over the design, so I'd love to see a proper template system in place.
That said, I'm not clear where this project stands. I've been reviewed the summary from last summer's SoC work, and while that's given me some idea of what was done, I don't have a good sense of how and where to get started on helping. Can you all offer some suggestions about what I can do to be helpful and contribute?
Aaron
Jon Reese writes:
My desired hopes would include Mailman 2.1.9 support for Python 2.2.3 without patches or changes to Python coding (for users of RHEL3 and CentOS3);
This is a cart-horse inversion IMO.
Let's get the template system, with whatever Python and email module Barry feels like mandating, and *then* think about backporting to other Python versions.
On Sun, 2007-04-29 at 17:12 -0500, Jon Reese wrote:
Unfortunately there are a number of package related versions that cannot be upgraded easily because the packagers have not brought the RPMs up to date with the current stable release of Mailman (2.1.9). They may have reasons for this, including versions of Python that are supported in various packages as well as their own development cycles and lack of manpower. If I am not mistaken, RHEL3, and CentOS3 are still relegated to Mailman 2.1.5 due to a reliance on an earlier version of Python (again the packagers have not upgraded the RPMs). I have at least two machines that I would like to bring to Mailman 2.1.9, but it would do more harm than good and other factors prevent OS upgrades.
My desired hopes would include Mailman 2.1.9 support for Python 2.2.3 without patches or changes to Python coding (for users of RHEL3 and CentOS3);
Perhaps you are laboring under a misconception concerning package upgrades within RHEL. By definition RHEL is version stable, once a version of RHEL is released a package never undergoes a version upgrade otherwise it would violate the guarantee of stability. There are of course some exceptions, occasionally RHEL will upgrade a package version in extraordinary circumstances, but there is nothing here which suggests mailman falls into this category.
If you would like to upgrade the mailman version on RHEL3 you can do so yourself, either directly via the mailman source distribution or by installing an RPM from another release, but this would be a site customization unsupported by Red Hat.
John Dennis <jdennis@redhat.com>
Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007
Developers and Admins,
It is understandable that some admins request a Mailman that works on their RHEL3 or older. But please don't let that hold development back at all. Admins really should appreciate that the developers look forward and focus on creating a system that is state-of-the-art. What they come up with now will probably be easy to install on RHEL5, and it will probably be included in RHEL6.
RHEL3 is a "don't touch it if it works" system. And it probably works quite well. And if a part of the system has to be upgraded, then upgrade the whole system to RHEL5.
And if upgrading isn't an option: It doesn't take long time to build a /usr/local/python2.5-for-mailman-only/ on an old system!
/Mads RHCE
On 27-Apr-07, at 4:53 PM, Aaron Crosman wrote:
That said, I'm not clear where this project stands. I've been
reviewed the summary from last summer's SoC work, and while that's given me
some idea of what was done, I don't have a good sense of how and where
to get started on helping. Can you all offer some suggestions about what
I can do to be helpful and contribute?
I'd also like to know where this stands. I wasn't too sure what was
happening after the SoC work finished, but it sounds like we got a
lot of good analysis but no clear path to a solution that worked for
us. Which is good work, but I'd still like to see some simple
templating available even if we can't solve world hunger in the
process. ;)
I think there may be some good patches out there that at least made
our CSS/HTML better. A search of our bug tracker (and probably this
list) could turn those up as a potential starting point. Right now,
taking a look at the listinfo page for this list turns up a lot of
BGCOLOR="#99CCFF" and such, and few divs and such to make changing
the look easier. I'd like to see something more modern, HTML-wise,
so that changing could be done with a stylesheet. If you've got
some time to find existing patches, Aaron, or to produce some, I'd be
happy to review and help get these integrated into svn, assuming no
one has vast objections to this.
Ideally, I think it should be possible to skin mailman just using
CSS, so I'd say we should start there. And once that's done, maybe
someone could sit down and try making a few different skins so people
can have some enriched examples? read: examples with some
documentation inline so people can modify them easily.
I think that could be a good starting point, since no matter what
further templating we want to do, getting workable (X)HTML coming out
of the interface seems like it would be a useful step.
Terri
PS - I'd also like to make our interface more usable, but making it
easy to use with stylesheets is a good goal even if we don't change
any of the content. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 30, 2007, at 11:41 AM, Terri Oda wrote:
Ideally, I think it should be possible to skin mailman just using CSS, so I'd say we should start there. And once that's done, maybe someone could sit down and try making a few different skins so people can have some enriched examples? read: examples with some documentation inline so people can modify them easily.
I think that could be a good starting point, since no matter what further templating we want to do, getting workable (X)HTML coming out of the interface seems like it would be a useful step.
Terri
PS - I'd also like to make our interface more usable, but making it easy to use with stylesheets is a good goal even if we don't change any of the content. :)
Let me add something else. The trunk may not be stable enough to
actually do much of the u/i rework yet. I'm really trying to spend
all my spare time getting the trunk to a stable place, based on
SQLAlchemy for the back-end. It's a disruptive chunk of work, but
I'm making progress.
If there are folks who want to start working on a new web u/i, either
to integrate a new templating system, or to prototype better content
or usability, then in the short term the thing to do would be to
branch Mailman 2.1 and let you have at it. In order to get commit
access, you'll need to assign your changes to the FSF. I can help
you get all that paperwork in place.
What do you think about going down that route?
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjdEhnEjvBPtnXfVAQLfkAP+P4CzeuZqGSHy9iOh3dClbzwk97hKd1uj K/vVfY8v8xIB/8aHopmR+HERGa+RNTkznMKv6/E7ZnG6D1F7OT58YmhCarvcS5u+ fCkm0Rs+81WaU11KrqwTXpvYIl4zXYr2mcYQ1qgbAq5zXzxv8KuCOF4vAFC7mo6Z 89BoFzasak8= =H28e -----END PGP SIGNATURE-----
Barry Warsaw wrote:
If there are folks who want to start working on a new web u/i, either
to integrate a new templating system, or to prototype better content
or usability, then in the short term the thing to do would be to
branch Mailman 2.1 and let you have at it. In order to get commit
access, you'll need to assign your changes to the FSF. I can help
you get all that paperwork in place.
Hello! After much absence I am something on the order of back.
I have just landed a contract that will allow me to 'continue' my work on the mailman web ui, and my semester is ending, so I will actually have some time.
Having struggled mightily to find a way to improve templating while not moving to python 2.4 (at least), I have to confess I don't think there's a good way to get there.
I tried a couple of "scorched earth" approaches and I think that was part of why I didn't get something that worked.
Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets.
I would dearly love to have anyone to work with on this project.
... oh yeah, and I will submit my paperwork to the FSF June 1st, which I know is "hella late".
~ethan
From my reading of the responses to my question I see two ways that people are thinking of proceeding, which I think might complement each other well.
First, there's the approach of fixing the current pages by moving the style information out of the Python code and into a CSS file. Second, there's the more extensive work to switch to a proper templating system like Genshi. I think in the long run, getting all the XHTML into external files is where the project should go. That will give users the most freedom to redesign how they see fit (good design of the default templates would still have that be styled using CSS), but it looks like there are a lot of work to make good progress in that area. I'd like to suggest a mixed approach. If we started to working fixing the 2.1 branch to have better output (even if it's never properly released), that would allow some people to do useful work while Barry firms up the trunk and we make a final choice of a templating engine. Once a template engine is inserted, that improved output could serve as the basis for the first templates for the system. Also, while we're finding a changing the HTML in the current python code, we could mark that code to be easy to find later.
We also need to attend to the "creaky decade-old look", but I would suggest that really be taken on as part of the work to move to a real template system, not as part of picking off the low hanging fruit.
Aaron
Aaron Crosman wrote:
From my reading of the responses to my question I see two ways that people are thinking of proceeding, which I think might complement each other well.
I'm reading this thread with interest, as the problems of working with the current templates are really why I'm on this list even though I've never got round to raising the issue!
Can I request that if the templates are being re-written some attention should be paid to the idea of making Mailman embeddable within a parent site's HTML framework and styles. For example, I run a system called HepForge where several content sources are hidden behind Apache and the page headers and footers, including CSS imports, are added by Apache output filters. A significant amount of work is currently required to edit Trac and Mailman templates to make them work with this sort of system - see http://trac.edgewall.org/ticket/4264 for a bit more detail on the issues with Trac's templates. This is a problem which is largely agnostic to the templating technology used and has more to do with design.
In particular, it would be really nice if
- the bits of the template which define <head>, <body> etc. are defined in one pair of header and footer files, so they can be turned off easily;
- the CSS files "namespace" everything by placing all Mailman content within a div, e.g. <div id="mailman">...</div> and then prefix all CSS rules with "#mailman" - this stops the Mailman styles from leaking out into the parent page elements.
I can add this to the wiki if it's useful. Is it?
(Sorry to dwell on implementation specifics at this stage, but it's an issue that's often ignored but is actually pretty important to people who want to incorporate external packages into their own framework.)
First, there's the approach of fixing the current pages by moving the style information out of the Python code and into a CSS file. Second, there's the more extensive work to switch to a proper templating system like Genshi.
Genshi has been mentioned a few times. My impression was that it insists on producing valid XML output, which is nice, but doesn't necessarily play well with ideas like factorisable head/foot portions. Also, can it be used for templating the automated email messages, i.e. plain text rather than XML? I'm not speaking from exceptional familiarity with Genshi here, but these suspicions made me use Cheetah in place of Genshi for one of our projects... can anyone confirm/refute these prejudices (off-list if necessary)?
Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 1, 2007, at 5:18 PM, Andy Buckley wrote:
In particular, it would be really nice if
- the bits of the template which define <head>, <body> etc. are
defined in one pair of header and footer files, so they can be turned off
easily;- the CSS files "namespace" everything by placing all Mailman
content within a div, e.g. <div id="mailman">...</div> and then prefix all CSS rules with "#mailman" - this stops the Mailman styles from leaking out into the parent page elements.I can add this to the wiki if it's useful. Is it?
It is, please do!
I see a couple of stops along the web u/i configurability track.
Most sites won't care and will just use Mailman right out of the
box. Others will be content with just tweaking a little CSS to get
their colors right. Still others will want to embed the Mailman u/i
in their own web pages. And finally, hard core users may want to
ditch the u/i all together, writing their own or running Mailman
without a web u/i at all. I think we can and should support all of
these scenarios.
Genshi has been mentioned a few times. My impression was that it
insists on producing valid XML output, which is nice, but doesn't necessarily play well with ideas like factorisable head/foot portions. Also,
can it be used for templating the automated email messages, i.e. plain text rather than XML? I'm not speaking from exceptional familiarity with Genshi here, but these suspicions made me use Cheetah in place of
Genshi for one of our projects... can anyone confirm/refute these prejudices (off-list if necessary)?
Please keep it on-list. I'm interested in the discussion too! I
forgot to mention Cheetah -- Ethan, did you play with it at one point?
Templating the email messages would be nice to have, but it's not as
critical as the web u/i.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjiSyXEjvBPtnXfVAQJFvwP/XrSSoBe3zByYL9YHGUj3N61pq53GajhQ hKsJz1zAaWBmXfChrOvhR4nhJyGFRZ/P+rKT67q4oXkYAgFDJqRpTL8aKupwaw1S C5oV8MPy0yJ7GFUjHaS0WueNYHPVGana1CQQSkkpF0xBxbYyHLQPuZBEf/IXURDG NlnO88zK098= =LEdB -----END PGP SIGNATURE-----
Barry Warsaw wrote:
Genshi has been mentioned a few times. My impression was that it
insists on producing valid XML output, which is nice, but doesn't necessarily play well with ideas like factorisable head/foot portions.
It doesn't; it has an HTML output mode. Yes, you should have a combined header and footer, but that's not a big obstacle to factoring.
be used for templating the automated email messages, i.e. plain text rather than XML?
Genshi can be used to generate plain text, yes.
Please keep it on-list. I'm interested in the discussion too! I
forgot to mention Cheetah -- Ethan, did you play with it at one point?
I don't care for cheetah because it's another one of those php-style markup approaches.
Genshi is really the best templating there is for Python right now, imo; I would be reluctant to use anything else.
~ethan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 1, 2007, at 1:04 PM, Aaron Crosman wrote:
From my reading of the responses to my question I see two ways that people are thinking of proceeding, which I think might complement each other well.
First, there's the approach of fixing the current pages by moving the style information out of the Python code and into a CSS file. Second, there's the more extensive work to switch to a proper templating
system like Genshi. I think in the long run, getting all the XHTML into external files is where the project should go.
Totally agreed. One of the design goals of the trunk is to allow
people to run Mailman without the web u/i, e.g. driven by Zope, TG,
Django, etc. Once I get a little farther with my SQLAlchemy/Elixir
branch, the next thing I'm going to do is egg-ify the code. I
desperately want to get rid of configure.
That will give users the most freedom to redesign how they see fit (good design of the default templates would still have that be styled using CSS), but it looks
like there are a lot of work to make good progress in that area. I'd
like to suggest a mixed approach. If we started to working fixing the 2.1 branch to have better output (even if it's never properly released), that would allow some people to do useful work while Barry firms up
the trunk and we make a final choice of a templating engine. Once a
template engine is inserted, that improved output could serve as the basis for the first templates for the system. Also, while we're finding a changing the HTML in the current python code, we could mark that
code to be easy to find later.We also need to attend to the "creaky decade-old look", but I would suggest that really be taken on as part of the work to move to a real template system, not as part of picking off the low hanging fruit.
Agreed.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRje4jHEjvBPtnXfVAQLm9wQAqhU2ISlP0j5jD9OKBlc6Nc2F/qJSuSfB yxWk0YZXNUAcgzOc58NXL6fxyjd/112A5ait+1/WhgyCLOhrzwujrn3NMGldNYOf XkiUDKuko4F2Fi4/ELdX8uoBSUeGAXAheRZZXFLGavlUVzwKi6dPRnn7/RJyh2yf FIpoLOr0Yk0= =dhpL -----END PGP SIGNATURE-----
Ethan, welcome back.
Aaron, I like your idea of a multi-pronged approach and am very willing to focus on specific files or whatever portions that you or Ethan would like me to.
Terri, I also like the idea of the "skin" approach and other UI systems that I have developed for did use that approach. It makes a good deal of sense if the list administrator could change the look and feel by selecting a "skin" from a predefined set. Perhaps, a series of CSS files in the form of "skin_name.css" inside the template directory.
If the results can be used in MM 2.1 and make the forward movement of MM 2.2 that much easier, then I am all for it.
I can probably donate 4 to 8 hours a week starting immediately or as required.
John, I apologize if you thought I was poking at RHEL. Actually, just the opposite. I appreciate the stability and support offered by the packaged structure and do understand the bugfix policy. I just hope to extend any benefit to other users of RHEL in a way that is easier to implement.
Is there a way that I can use the withlist command to change the display name of a mailman list?
- On 2007.05.02, in <83EB3FBBDF867245A54F47D4136B68C5D0E4B5@PHXDCEX012.phx-dc.dhl.com>,
- "Jeff Kunzelman (DHL)" <Jeff.Kunzelman@dhl.com> wrote:
Is there a way that I can use the withlist command to change the display name of a mailman list?
You can, but you must write valid python code that manipulates properties of the list object. Withlist's function is to instantiate a list object to facilitate these manipulations.
This attached program is something we developed here for uchicago.edu some years ago, and have been using for a variety of batch and/or bulk manipulations of list properties. It's a bit more convenient than withlist or the config_list program that appears is more recent Mailman versions. In short, you can use configlist to display or set any list property *entirely on the command line*. Values are displayed as python expressions, and when setting a value, it must be set to a valid expression, but you don't need to write any actual code.
I don't think that I've posted this before -- I'm sorry if I'm wrong about that. Feel free to use it without any warranty, etc.
Examples: $ configlist.py mylist [ shows all properties of the list as python expressions ]
$ configlist.py mylist description description: 'This is the display name as shown on the listinfo page.'
$ configlist.py mylist description="'The mylist list is for me.'" [ sets description. Note the redundant quoting to protect the python expression from shell. ]
$ configlist.py mylist description=s/mylist/MyList/ [ use the s/// expression to munge the existing value of description ]
Configlist.py can be rather dangerous, because it allows changing any list property at all without any of the constraints that may be built into the web UI. Be sure you know what you're doing. You can use configlist.py before and after a web UI change to get a feel for how to script the same change in the future.
I apologize that the code is probably horrific to python enthusiasts. It was among my first efforts and I've not revisited it since actually learning the language.
-- -D. dgc@uchicago.edu, an Element of NSIT University of Chicago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 1, 2007, at 11:47 AM, Ethan Fremen wrote:
Having struggled mightily to find a way to improve templating while
not moving to python 2.4 (at least), I have to confess I don't think
there's a good way to get there.
That shouldn't be an obstacle for the Mailman trunk. Python 2.5 is
required. Does this help give us a good way to get "there"?
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRje36XEjvBPtnXfVAQJCLQP+KoNHXbDF3NYtpL1Ei5GKoQgiKuEglZcd vmJNnIg0DUoihocMk7y7RUAUcB+geiMCFpTgti13lhnMUO+1j1X2zl/IpJmv0D04 OQUp6UHCkLqGcvFylR1t2PE1Kw74pijRyr3LNn8ihcDaeUt+WuHaFoBfct1Ui1N7 M4VrnnvrE40= =X+GX -----END PGP SIGNATURE-----
On Tue, May 01, 2007 at 11:47:40AM -0400, Ethan Fremen wrote:
Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets.
Agreed. I'd be happy to embark on that effort while waiting for the trunk to settle down.
--amk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 2, 2007, at 10:21 AM, A.M. Kuchling wrote:
On Tue, May 01, 2007 at 11:47:40AM -0400, Ethan Fremen wrote:
Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets.
Agreed. I'd be happy to embark on that effort while waiting for the trunk to settle down.
It sounds like the right course of action is to branch the branches/ Release_2_1-maint branch to let you guys hack on this. How about
branches/modernize_21_webui
?
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjijzXEjvBPtnXfVAQKoTwQAr8Fr2XPEQj/KOqAt/9+kuIiyp8S5r8UK GWF2rWwlpRkjAbbF13sruUO7G613h5vbnHhhZ4sFEOdKHDn+swCj2GpxeVu3VzTW N1e1/PUHCjX0bOjfIbtF8PtClA7vlZCPfNdKMqIcO2FNVKWpq1oWLJwWqpP9Xd5k MPPUJjXs610= =wYzS -----END PGP SIGNATURE-----
Barry Warsaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 2, 2007, at 10:21 AM, A.M. Kuchling wrote:
Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets. Agreed. I'd be happy to embark on that effort while waiting for the
On Tue, May 01, 2007 at 11:47:40AM -0400, Ethan Fremen wrote: trunk to settle down.
It sounds like the right course of action is to branch the branches/ Release_2_1-maint branch to let you guys hack on this. How about
branches/modernize_21_webui
great by me!
~ethan
Let's see if python.org is ok with me now...
Barry Warsaw wrote:
If there are folks who want to start working on a new web u/i, either
to integrate a new templating system, or to prototype better content
or usability, then in the short term the thing to do would be to
branch Mailman 2.1 and let you have at it. In order to get commit
access, you'll need to assign your changes to the FSF. I can help
you get all that paperwork in place.
Hello! After much absence I am something on the order of back.
I have just landed a contract that will allow me to 'continue' my work on the mailman web ui, and my semester is ending, so I will actually have some time.
Having struggled mightily to find a way to improve templating while not moving to python 2.4 (at least), I have to confess I don't think there's a good way to get there.
I tried a couple of "scorched earth" approaches and I think that was part of why I didn't get something that worked.
Right now, I think the "low hanging fruit" is to rip out all the HTML 'style' markup and make all the style applied via stylesheets.
I would dearly love to have anyone to work with on this project.
... oh yeah, and I will submit my paperwork to the FSF June 1st, which I know is "hella late".
~ethan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 27, 2007, at 4:53 PM, Aaron Crosman wrote:
That said, I'm not clear where this project stands. I've been
reviewed the summary from last summer's SoC work, and while that's given me
some idea of what was done, I don't have a good sense of how and where
to get started on helping. Can you all offer some suggestions about what
I can do to be helpful and contribute?
I think the SoC work is interesting from an experimental standpoint,
but we're probably going to have to re-do most of that work for
inclusion in the trunk.
Because Mailman 2.1 is in stable maintenance release, we can't
officially include any changes to its templating system. Mailman
trunk is where the work should be conducted, and I'm all for getting
folks to help out with this effort.
There are several problems with MM2.1's web u/i, aside from the
obvious creaky decade-old look, and css and xhtml-unfriendly style.
The big problem is that there /is/ no one templating system. Some of
the web pages are generated from Python code, some are substituted in
from the language-specific templates. The problem with the latter is
that every natural language has its own copy of the templates, so if
you change the English version (say to add a widget), you've now
broken all the other languages.
What I would really like to see is the adoption of one of the state-
of-the-art Python-based templating systems, and converting the entire
Mailman web u/i to use this system. It's too early to mandate
something, but Genshi <http://genshi.edgewall.org/> seems like the
prime candiate.
I've personally tried ZPT and had lots of problems when I started to
internationalize it. I believe Ethan used Kid in the SoC branch
initially and ran into problems there too. He may have moved to
Genshi toward the end of the project. I know there are many other
templating systems out there, such as PTL (from Quixote) but I don't
have much experience with them. I would encourage folks who have
experience with templating systems to throw their hats in the ring
here, or if you want to help out with this effort, go download some
of these systems and try them out, and report back here.
We'll use http://wiki.list.org/display/DEV/TemplatingNotes to keep
track of this project. I know Andrew Kuchling is quite interested in
this project too, especially as it pertains to the archiver, since
the next gen archiver will use the same templating system.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjdDrXEjvBPtnXfVAQI2PQP/bWUry7bGw6ISOwBslxCpUQ8IRNWX6Asw uj8oCGEQatZZuhx9cpS/TEM51qh4Q3vXRw9sL0DBfncS1F7v1nwKX5R51BDC1VoR hLIMh/CImQniSHHjrJ0+eeAMPCQvAc/QcT9THoB1Y+j+jxSiUDYESlIfbUzmY6wN 2Y+2RAZEhfo= =0RIN -----END PGP SIGNATURE-----
On Tue, May 01, 2007 at 09:41:58AM -0400, Barry Warsaw wrote:
initially and ran into problems there too. He may have moved to
Genshi toward the end of the project. I know there are many other
templating systems out there, such as PTL (from Quixote) but I don't
have much experience with them. I would encourage folks who have
I think the critical question is audience: who will be customizing Mailman? Can we assume they know XML? can they keep their HTML well-formed XML? will they use an HTML editor or just a text editor like vi/emacs?
Some toolkits (Genshi, ZPT, Nevow) demand that the input be well-formed XML and work to ensure their output is well-formed. Here's an example from the Nevow for python.org:
<n:slot name="items">
<n:invisible n:pattern="item">
<li class="group">
<a href="/web"><n:attr name="href"><n:slot name="href" /></n:attr><n:slot name="label" /></a>
</li>This produces <a href="{content of href slot}">{content of label slot}</a>.
Other toolkits don't enforce this: you write something like:
<ul class="quicklinks">
%for link_2, level3_links in level2_links:
<li>${link_2.as_html()}</li>
%endfor
</ul>Make a typo and change </li> to </lo>, and this will happily generate bad HTML. But it's also easier to hack away at a page and generate output, albeit possibly-invalid output.
So, who do we picture customizing Mailman's templates? Core developers? Sysadmins? Skilled web designers? Beginning web designers?
(I'd rule out Quixote's PTL: too idiosyncratic, and Mailman's target audience may want to customize the look while not knowing Python. Plus the import hook complicates life.)
--amk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 2, 2007, at 10:22 AM, A.M. Kuchling wrote:
On Tue, May 01, 2007 at 09:41:58AM -0400, Barry Warsaw wrote:
initially and ran into problems there too. He may have moved to Genshi toward the end of the project. I know there are many other templating systems out there, such as PTL (from Quixote) but I don't have much experience with them. I would encourage folks who have
I think the critical question is audience: who will be customizing Mailman? Can we assume they know XML? can they keep their HTML well-formed XML? will they use an HTML editor or just a text editor like vi/emacs?
Great questions, thanks Andrew. Here are my thoughts, but I'm open
to other opinions.
Related to the different levels of customizability, I'd say that it
should be easy for folks to change some color schemes and basic look
with just a passing understanding of CSS. That suggests weekend
warrior web designers with a text editor and something like http://
www.w3schools.com/css/default.asp open in their browsers.
So, who do we picture customizing Mailman's templates? Core developers? Sysadmins? Skilled web designers? Beginning web designers?
For anything more complex, I think our audience is skilled web
designers and experienced developers. As much as possible, I'd like
for someone who is a moderately to very skilled web designer, and
understands XHTML and XML but probably not Python, to be able to do
80% of the web customization they'd need. I think it's okay if we
relegate the really complex 20% (e.g. ditching our wsgi web publisher
and integrating with Zope) to be a skilled Python developer.
One thing this will require from the core is moving all the logic out
of the Mailman/Cgi modules and into the core libraries. This will
also make it feasible to mirror more of the web functionality into
other channels, such as email and command line (or possibly even a
fat u/i interface). That's a task that's on my list for the trunk.
(I'd rule out Quixote's PTL: too idiosyncratic, and Mailman's target audience may want to customize the look while not knowing Python. Plus the import hook complicates life.)
That's great to know, thanks!
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjiq33EjvBPtnXfVAQJfPwP/YVaBXtt8QUsJQ+1bO5Mctvaj0ChAdAe2 TS52Mc3Zk0jSKWL7eCMKbUpyvTS5s87wtTUAi2jq6VietyErRotDT4Gj8gCCpWo0 gtCzOemC9VkicWAuc02D1MtYjXPVOlVmezU9yKrjJIn3KVoUiGqP8Y9LGvyj3umN o7rDqO7jIww= =mMNm -----END PGP SIGNATURE-----
Barry Warsaw wrote: \
Related to the different levels of customizability, I'd say that it
should be easy for folks to change some color schemes and basic look
with just a passing understanding of CSS.
I agree with this, and think that a vast swath of customization needs could be met with CSS manipulations only, assuming the (x)html is decent.
CSSZenGarden.com is a good example of this.
To clarify the situation with Genshi a tiny bit, it does have the capability to deal with less-than-flawless xml; which is good because you have to break certain rules sometimes to make browsers do the right thing.
One thing this will require from the core is moving all the logic out
of the Mailman/Cgi modules and into the core libraries.
What are the "core libraries" in this context?
~ethan
participants (12)
-
A.M. Kuchling -
Aaron Crosman -
Andy Buckley -
Barry Warsaw -
David Champion -
Ethan Fremen -
Jeff Kunzelman (DHL) -
John Dennis -
Jon Reese -
Mads Kiilerich -
Stephen J. Turnbull -
Terri Oda