Better documentation of things to avoid in the comments framework
|Reported by:||subsume||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
I got myself into a situation with a project and some comments models. Perhaps with some discussion we can uncover genuine code-bugs, but my knowledge about this is limited and so I'm just calling for a documentation update. A major reason I'm asking for some notice of these things to appear somewhere is that all of the below seems to work perfectly fine in the dev server. On deployment, its a confusing catastrophy that, at best, gives you a vague ImproperlyConfigured("The COMMENTS_APP setting refers to a non-existing package."), which is of course no help at all.
1) Its not obvious to me why, but importing a custom comment model as 'Comment' seems, somehow, to get back upstream to django.contrib.comments and wreck things. If this is due to the nature of that particular frameworks' immaculate ability to be extensive and provide conveniences all around, so be it. I'd just like a notice next time before I attempt to save code by doing Comment = comments.get_model() and expect everything to be honkey dorey.
2) A custom comments app should not also be called 'comments'. Probably a very obvious one but the problems it creates are inconsistent between dev and live and not obvious.
3) Models hoping to foreignkey to whatever comments model the app provides should not be passed the callable. I realize passing callables into a ForeignKey probably seems strange in and of itself, however, once again it creates inconsistent problems between dev and live which never connect back to the FK in any obvious way.
Change History (10)
comment:1 Changed 5 years ago by subsume
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
comment:6 Changed 5 years ago by russellm
- Resolution set to invalid
- Status changed from new to closed