Changes feature APIs? Implementation? Decision? ------------------------------------------------------------------- newforms Yes No, but on the way Yes serialization No No No authentication Yes Yes Yes generic relation Yes No Yes comments No No, but jacob takes Yes oracle No Almost Yes test fixtures No Yes Yes root views/url rev. Yes No No autoescape No Almost AlmostComments: Jacob plans to rewrite them for newforms. I'd say this change actually belongs into the category 'newforms'. I'm not entirely convinced that it is necessary to rewrite the comments in 1.0, though. Other than the changes in admin, the comments system rewrite shouldn't directly influence the API of newforms.
There had been some discussion in late October regarding upcoming changes to the Comments API and how it might look under 1.0 once newforms was in place. Is the intention to keep the *model* for Comment and FreeComment the same while using newforms to revise view/template logic? Some ideas for changing the underlying structure included: * merging Comment and FreeComment * supplying an abstract class and deriving Comment and FreeComment (and potentially other user-derived Comment classes) from this class. Does this depend on ModelInheritance? Seems so. * setting up an API that "Comment" implementations can respond to. In essence, I think the suggestion was to try and duck type comments. I cannot tell if the previous discussion had ever been resolved. Jacob, your thoughts? I have noticed a few discussions around the hacking of FreeComment and I wonder where this piece, in particular, is going. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
