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