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

[Richard Wackerbarth]

I believe that it may be your intention to have kept "postorius" hidden. But I don't think that the actual implementation has accomplished that.

Please see ~mailman-coders/postorius/trunk : /src/postorius/templates/postorius/base.html (revision 65) at lines 11 - 16

Clearly, this file is a part of the postorius app and not the dev_setup site.

And you seem to have missed my point in suggesting that we deliver two themes. I recognize that Django has a good mechanism for the implementation IF the user templates are written in a generic manner. However, all too often, in many projects, I find that the actual code written fails to adhere to the necessary standards and is therefore very difficult to port to an alternate implementation.

If we force ourselves to maintain two, significantly different, implementations, we are much more likely to remain within the design standards and thus have something that an end-user can readily customize for their own use.

Richard

On May 21, 2012, at 10:26 AM, Florian Fuchs wrote:

> 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'.

>> 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