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

[Florian Fuchs]

Am 22.05.12 13:14, schrieb Richard Wackerbarth:
> On May 21, 2012, at 8:33 PM, Stephen J. Turnbull wrote:
>> I don't understand your point.  For better or worse, CSS is tied
>> to the HTML it styles via id and class tags, and element nesting 
>> patterns.  Another app for presenting list admin functions would
>> have different HTML and different CSS.  So a site which wishes to
>> customize the appearance of postorius will need to add
>> postorius-specific CSS anyway, which may as well be indicated by a
>> path element in the URL.
> 
> Yes, but one of the design points of Django is that, without a great
> deal of effort, the user can customize his site URLs in any manner.
> Further, doing so follows the DRY principle. Embedding the actual
> text stream "/postorius/" in templates, particularly multiple times,
> is a violation of this design.

Again: This is not generally true. It is true for hard-coded *page* URLs
in templates. One really should use the `url` template tag for this. So
*if* you find hard-coded *page* links in postorius, consider it a bug
that needs to be fixed.

But having the app name (in our case: the text stram "postorius") appear
hard-coded in *static file* paths (CSS/JS etc.) in base.html is, in
fact, a wide-spread and very useful Django convention. After all, the
app's name is "postorius" and as such it is the reference point for
Django, needed for template overrides and static file collection.

Even Django's own contrib apps handle it like this.

> Following the design, the user will specify the appropriate prefix
> for the subsystem dependent static files as a part of the settings.
> The default value will include "postorius". However, since most users
> view the GUI to be a part of the larger mailing list system, I could
> argue that "mailman" might be a better choice.

A prefix is not the recommended approach any more. In fact the
"admin_media_prefix" context variable in django's own contrib.admin app
is now deprecated, because that's exactly what
contrib.staticfiles/collectstatic and template overrides can do better.

If you'd like to have urls like "/mailman/lists/new" instead of
"/postorius/lists/new", or even "/mailman/come/on/lets/add/a/list":
Fine, you can do that. But if you want to use different static assets,
you need to override the template.

> You are also missing the fact that postorius is intended to be a
> subsystem within a larger website,

There is probably more than one opinion on what Postorius is intended to
be. If you ask me, it is more than just that. A subsystem in an existing
site, yes. But also a stand-alone mailing list management app that you
might serve on a specific (sub)domain. And also (hopefully, in the
future) part of a collection of other mailman-related django apps
(although in that case, you could argue that it's a subsystem).

> that it would follow the same structural design. Since both of these
> subsystems cannot be the source of the essential boilerplate, we
> would have to force one of them to defer to the other. It is a poor
> design to create an artificial dependency between the two subsystems.
> Rather, both of the subsystems should defer to the main site since
> they are a subsection of it.

I really like the idea of independent and easily pluggable apps. But it
obviously has some downsides. I bet we're not the first ones argueing
about the best way to plug different Django apps together. That's why
I'd rather talk about how to find a "good solution" but about a "poor
design".

>> A different question: what happens if MAILMAN_THEME is set to
>> "foo", and postorius doesn't have a "foo" theme?  I think it would
>> be obnoxious to require all customizers to customize everything.
> 
> I agree. However, I think that it is a mistake to build themes for
> the entire website into the postorius app itself. Using a theme app
> is a better design. 

See my reply to Steve's previous post...

Florian