Revision history [back]
The logic behind a separate group for each user is to handle access to the content by group uniformly - both for users and the user groups. This is not required if you are not using the user groups feature, so you can just ignore those per-user personal groups.
We've patched the auth_users
directly to add extra fields. People have criticized this, but I've never heard a report of a real collision - i.e. the field we've added was also added by a third application and where there was a real impossibility of using Askbot with other apps due to this issue. If someone reports such collision we could either prefix the patched fields or move them into AskbotProfile
.
The profile elements necessary for different apps can be split into separate tables or put into one. One might think that the first method is better, but then one might end up with having the same data duplicated in the multiple tables and will need to be synchronized, plus you'll need to make extra db queries to load that data.
The rationale for using Jinja2 templates is described on other answers and there are blog posts about that, the reasoning is quite general, nothing really specific to Askbot. I don't know of any advantages of the Django templates over Jinja2, except that they are a default choice made for you by the Django delevopers.
It's possible to mix Jinja2 and Django templates in the same project via django's template loaders settings, but of course one can rewrite the templates if desired. One might also consider rewriting their other templates for the faster Jinja2 engine. The speedup with Jinja2 becomes noticeable when the templates have many {% .. %}
and {{ .. }}
elements, but in the simple templates there won't be as obvious.
The logic behind a separate group for each user is to handle access to the content by group uniformly - both for users and the user groups. This is not required if you are not using the user groups feature, so you can just ignore those per-user personal groups.
We've patched the auth_users
directly to add extra fields. People have criticized this, but I've never heard a report of a real collision - i.e. the field we've added was also added by a third application and where there was a real impossibility of using Askbot with other apps due to this issue. If someone reports such collision we could either prefix the patched fields or move them into AskbotProfile
.
The profile elements necessary for different apps can be split into separate tables or put into one. One might think that the first method is better, but then one might end up with having the same data duplicated in the multiple tables and will need to be synchronized, plus you'll need to make extra db queries to load that data.
The rationale for using Jinja2 templates is described on other answers and there are blog posts about that, the reasoning is quite general, nothing really specific to Askbot. I don't know of any advantages of the Django templates over Jinja2, templates, except that they are a default choice made for you by the Django delevopers.
It's possible to mix Jinja2 and Django templates in the same project via django's template loaders settings, but of course one can rewrite the templates if desired. One might also consider rewriting their other templates for the faster Jinja2 engine. The speedup with Jinja2 becomes noticeable when the templates have many {% .. %}
and {{ .. }}
elements, but in the simple templates there won't be as obvious.