On Thu, 2006-10-26 at 11:29 -0700, Rob Hudson wrote: > James Bennett wrote: > > On 10/26/06, Rob Hudson <[EMAIL PROTECTED]> wrote: > >> Are there goals or docs about what this might become? There seem to be > >> enough people using the comments systems that maybe people could work > >> on a patch (or at least get started in the right direction) if there > >> were some goals and ideas on what's considered broken currently. > > > > IIRC, one of the big (and, to me, most interesting) suggestions > > involved changing the system so that you could write a model which > > conformed to a particular interface (e.g., FK to user, FK to > > contenttype and an object_id, plus maybe a couple methods), then drop > > it into a setting and have it be "the comment model". The ones we ship > > now should still be bundled, of course, and used as the defaults, but > > that would add a huge amount of flexibility to the system. > > I'm having trouble visualizing how that would work. I searched the list > and the tickets for more info but didn't find anything. > > Is the gist of the idea that you'd set up the model and a few methods > and the bulk of the work would get wrapped around that?
I think what James is suggesting (I may be completely wrong, though) is that we define the interface that the class must provide: so the comment class must have methods X, Y and Z and fields A, B, and C. Then people are free to write whatever class they like that meets those requirements in addition to extra methods their class might have (such as karma management, etc). Then, in settings.py, you put in the location of the class (model) to import that satisfies the required interface. Since comments requires the developer to design the template in any case, this should work quite smoothly. You will receive the full comment object (or list of objects) in the template, so you can extract information from any of your extra attributes without trouble. It might also be possible to achieve the same with model inheritance because the way we have decided to expose that is via an attribute on the base model. So if MyComment was a subclass of Comment, a Comment instance would have a mycomment attribute (or the name can be set by the user) that would provide access to the associated MyComment instance. Both of these ideas seem workable to me. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
