[Mailman-Developers] [Merge] lp:~wacky/postorius/csrf into lp:postorius

[Florian Fuchs]

Hi,

Am 20.05.12 16:22, schrieb Richard Wackerbarth:
> However, I am concerned that your implementation exposes "/postorius/" in the URLs and in the template names for the themes.

It doesn't - it's a simple configuration issue. The URL namespace for
Postorius is defined in the *project's* urls modules (in our case
`dev_setup/urls.py`), *not* in Postorius'.

You can easily change `postorius` to something else to define a
different namespace for all Postorius-URLs. You can also define
"postorius.urls" as the ROOT_URLCONF in your project to use no namespace
at all (this would of course only make sense for installation scenarios
where no url-collisions are expected, like a (sub)domain that serves
nothing but Postorius).

Remember that dev_setup is just an example django project that we put
into trunk for convenience' sake during PyCon. It is not part of the
Python-package that get's installed with Postorius. Although, as we
discussed recently, dev_setup should be moved to a separate location.

> 
> IMHO, all of this design seems to reflect a philosophy based on the idea that the purpose of the website is to run mailing lists. 

Quite the opposite. The whole idea of distributing postorius as a django
*app* and not a django *project* aims at making it easily possible to
integrate Postorius into existing scenarios. That's why the URL
namespace isn't defined in the app-level urls module.

> I think that we need to look at it from a different perspective. The use case is that of a company, organization, etc. that has a presence on the 'net. For example, their website is primarily an e-commerce site. The company runs a customer contact mailing list to which individuals can subscribe. Here, the postorius interface is a small subsection of the overall website. But, properly written, the display should appear to be a seamless addition to the content.

Absolutely. Both scenarios should be (and are) possible. A stand-alone
installation as well as integrated into an existing django-project.

> This implies that "themes" would apply to the whole site and not just the postorius section.  As such, I think that we should put the theme definition in a "theme" namespace rather than within the "postorius" namespace. 

The URL namespace you choose for the Postorius URLs has no effect on the
theme that is used. You could change the namespace to

    (r'^googlegroups/', include('postorius.urls')    # SCNR :-)

and django would still look for a template folder with the name
`postorius` (both in your app as well as your project). So overriding
the app's theme (or just single templates) on the project level would
work just like with every other django app.

For instance, you could override Postorius' base.html on the project
level to make it use your existing site's html/css layout.

> 
> I suggest that we deliver at least two themes. One would be in the style of "mailman" and the other that of "django". I suggest this because, if we cannot do both easily, it will provide some indication of the usability of our website structure.

We already have a MAILMAN_THEME setting (set to 'default') which you
could easily change to something else and add another theme folder to
the templates/postorius folder. We did that exactly with the idea in
mind to deliver more than one theme with the application.

However, I don't like the idea very much any more, because django
already has a very good system to override existing themes, either
through project-level overrides or through installing a "theme-only" app.

Florian