> Thanks for the info. You make some interesting points about the database
> not being able to enforce referential integrity.
>
> I hadn't thought of providing the comment model as a base class and
> having the users specialise it themselves. How would that work in
> regards to template tags? For instance if I had a template tag like this:
>
> {% get_comments for obj as var %}
>
> how would one hook in a user provided object with its own model which is
> not known ahead of time
In order to make this template tag work, your comments app just needs to
know what comment model exists for any given "commentable" model. You
could ask the user to explicitly tell you this, by calling some kind of
registration function. Or you can just listen to the `class_prepared`
signal [1], which fires after every model class is prepared; check if
the model class is a subclass of your abstract Comment base; if it is,
check for the required added FK (throw a clear error if they didn't add
it), see what model class it's pointing to, and add it to your registry.
or would you suggest using a template tag such
> as this instead? I guess letting the user explicitly state the
> application and the model themselves offers the best flexibility in the
> long run.
>
> {% get_comments for [app].[model] [object_id] %}
I don't think this variant of the template tag really helps anything;
given an `obj`, you can quite easily figure out what model class it's an
instance of (`obj.__class__` or `obj._meta.model`). You still have to
get from that "commentable" model class to its comment model class,
which requires the same registry I described above.
So I'd probably go with the first version, which is an easier API for
the template author.
Carl
[1]
https://docs.djangoproject.com/en/1.7/ref/signals/#class-prepared