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

[Stephen J. Turnbull]

Richard Wackerbarth writes:

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

I can't speak to the "multiple times" issue (it does sound like a
violation of DRY), but after arguing vehemently for multiple themes,
you now seem to be mistaking Postorius for a unique part of Mailman
(core).  It's not.  One could even imagine us sharing a site and you
insist on using Postorius for your admin duties while I prefer
CeterisAdmin, and having both installed.  Postorius-specific
components of a theme will need to be in a Postorius-specific
namespace.

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

I'm beginning to see your point, and I think I'm going to stay far
away from it (and most especially not devote any implementation effort
to it).  AIUI, Mailman itself doesn't currently provide a website
(although maybe it should, limited to the purpose of providing a
common framework for inserting Mailman-related apps into a larger web
site), and who knows what a "larger website" might provide.  So I
don't see how to implement that requirement.

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

Why would it do that anyway?  (I concede your jquery example, but I
don't think that would be hard to fix up.  The base template and base
CSS are hairballs OTOH.)  What I would expect is a (hopefully minor)
violation of DRY:

1. Designer designs Big Web Site.
2. Admin installs Mailman and Postorius.
3. Designer adds BigWebSite theme to Postorius (not a problem for
   Postorius-specific aspects)
4. including a BigWebSite base template and CSS (DRY violation!)
5. Admin sets MAILMAN_THEME to "BigWebSite".

Sure, I'd love to say "Postorius will inherit from the Big Web Site,
so we can omit 4", but I don't think we can.

 > We should assume that it would follow the same structural
 > design.

I disagree.  Postorius is being built so we can throw it away.  If
we're real lucky, maybe we won't have to, and if it's sufficiently
modular, maybe we can get away with only redoing the base template or
something like that.  But trying to make it all things to all Big Web
Sites now is imposing a huge burden on the Postorius implementers,
because it's almost certain they will get it wrong for some Big Web
Sites.  Let's leave them to do what they can get right.

Also, Postorius is an admin function, with complex internal navigation
needs.  I could see trying to make the user interface for managing
one's subscriptions conformant to a larger design, but the list and
site admins are necessarily going to see a Postorius-specific
navigation scheme.  It might be artistically better to leave that
entirely up to Postorius.

 > dependency between the two subsystems. Rather, both of the
 > subsystems should defer to the main site since they are a
 > subsection of it.

That would be OK if we had a specification of "main site"
(specifically how themes and navigation are implemented).  Do we?  I
don't see one (I don't even see reason to suppose it will be
implemented in Django!), but I may be missing something (I'm not a web
designer).