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

[Richard Wackerbarth]

On May 21, 2012, at 8:33 PM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> 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.
> 
> 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.

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.

> Note that STATIC_URL is site-specific, and if you want to add the
> postorius theme code in a site-specific place, add that place to the
> STATICFILES_DIRS setting.

STATICFILES_DIRS relates to the server-side storage of files. I am talking about the client-visible URLs used to reference them.

> What am I missing?

You are also missing the fact that postorius is intended to be a subsystem within a larger website, As such, it should be obtaining its "boilerplate", including the basic page layout, navigation menu structure, css, etc. from the parent website. That website should not be expected to invert the hierarchy and use files within the postorius namespace for pages that have nothing to do with the administration of the mailing lists. Remember, we must assume that there also might be some other subsystem (such as an e-commerce storefront) that will coexist with the mailing list.
We should assume 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.

> 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. Thus, "MAILMAN_THEME" would apply only to the specific content portion of the pages involving mailing list settings, etc. Since much of the "look and feel" for that content should be inherited from the surrounding page, I think it reasonable to require that the selected postorius theme components exist.

Richard