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

[Florian Fuchs]

Am 21.05.12 18:24, schrieb 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
> <http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/files/65/src/postorius/templates/postorius>/base.html (revision
> 65) at lines 11 - 16

If you are talking about the static file paths containing `postorius` I
don't see why we should break out of this very useful convention (or why
it should be contradictory to the goal to make postorius more customizable).

Having the app name hard-coded in static file paths is pretty common.
And for a good reason - for instance, if you use `manage.py
collectstatic` - which has the sole purpose of making app assets
available within a <STATIC_URL>/<app_name>/... folder structure (and is
essential for serving static files effectively and hassle-free).

Do we want to be able to customize the namespace in page urls? Yes. Do
we want to make it possible to override single postorius URLs (for
instance if you just want to use the subsription page on your site)?
Also yes. Those are basic django features and you can do that with
Postorius, too.

But if you want postorius to use different asset paths IMHO the django
way to do it would be to just override base.html. What we could do
though (we already have your bug report for that) is optimize
base.html's block structure a bit.


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

I agree, the goal is to keep the markup in the sub-templates (the ones
that extend base.html) as simple and generic as possible. In order for
them to work well even with a very different override of base.html. I'm
glad for every inconsitency you can find and report on that side (or
even fix it!). I'm sure there are things we can do better. It's still
alpha code after all.

Also, I'm very eager to clean-up the view code and add better testing at
the moment. So we definitely can use some help with the templates.

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

I agree - with the small exception that someone has to write that second
theme... ;-)

Florian