Hi Aurélien,
Thanks for the info! Some replies inline:
- HyperKitty uses the top-level template directory (eg. it has a
templates/base.html file), which is generally reserved for site-level templates.
- HyperKitty's base templates aren't broken up into blocks in such a way that
they can easily be used to extend a different base template. The base template defines
both the overall page structure and various HyperKitty components, so it's impossible
to, say, modify the navigation bar without replicating a large chunk of HyperKitty stuff.
I am not very familiar with Django conventions, so please feel free to point me to the
right direction. Pull requests are even more appreciated!
I can work on a pull request. The best practice that I've seen with regard to
template naming is to put the templates under an application-specific subdirectory, eg.
"templates/hyperkitty/template.html". I'm less sure about the template
layout -- I typically have a base layout that breaks the page into functional blocks
(header, navigation, breadcrumbs, body, footer) which get extended in application
templates, but that's just the product of my own trial and error, I'll look and
see if there's some more formal best practice documented somewhere.
- Moreover, both apps use the same view names in places. For
example, the HyperKitty user_profile page loads Ajax content from the
"user_subscriptions" view, but Postorius defines its own
"user_subscriptions" view that returns a full page. The result is that if the
main urls.py includes Postorius URLs after HyperKitty URLs, the HyperKitty subscriptions
tab tries to load the Postorius page via Ajax and fails.
Do you recommend prefixing the view names?
I've seen that suggested, but I feel like that results in awkwardly verbose view
names. Django supports namespacing (so you could say {% url
"hyperkitty:user_subscriptions" %}) but I haven't used this much and my
initial impression from trying it is that it's fairly fragile.
- Postorius uses BrowserID authentication through social_auth, while
HyperKitty includes a separate browser_id library
Yes, we are both migrating to the separate browser_id library, for security reasons.
Thanks, I will use that.
Also, I tried out the mailman-bundler package -- very convenient, thanks! Its config
lists the HyperKitty URLs last, so the HyperKitty pages look fine but you can see the view
name conflict from the Postorius page at
http://localhost:8000/mailman3/accounts/mailmansettings/ -- the "Profile" and
"Subscriptions" links go to HyperKitty.
Cheers,
Adam