#19904: Rework syndications contrib to use generic CBV's
-------------------------------------+-------------------------------------
     Reporter:  dokterbob            |                    Owner:  dokterbob
         Type:                       |                   Status:  closed
  Cleanup/optimization               |                  Version:  master
    Component:  contrib.syndication  |               Resolution:  wontfix
     Severity:  Normal               |             Triage Stage:  Design
     Keywords:  django-sprint cbv    |  decision needed
  syndication                        |      Needs documentation:  0
    Has patch:  0                    |  Patch needs improvement:  0
  Needs tests:  0                    |                    UI/UX:  0
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by lukeplant):

 I think you should open a new ticket for this.

 There are good reasons for the original API for feeds. There is the low
 level feed generator API in django.utils.feedgenerator -
 https://docs.djangoproject.com/en/1.5/ref/utils/#module-
 django.utils.feedgenerator for generating the XML of a specific feed
 format. It is entirely possible to use this in projects without ever using
 the high level API. This code is not "only used by the feeds contrib" - it
 is a publicly documented API in its own right. So I would be -1 on merging
 that into the high level API.

 I don't know in what ways you find the API hard to extend, but I think
 they should be the subject of another ticket, or perhaps several tickets.

 Also, I think your terminology is a bit confusing - usually you "refactor"
 an implementation i.e. leave the API alone, and change the internals. Or,
 you change an API (by introducing a new one, and deprecating the old one,
 in the case of Django). I'm not sure which you are suggesting.

 If you are proposing a new feed API, it will require significant
 justification. If you have very custom needs that the current high level
 API is ill-suited for, it is entirely possible to write your own high
 level API. The argument "it's not DRY" can be used to include everything
 possible in Django, which we will always resist. It has to be something
 that is demonstrated to be a common need, and where having external,
 possibly competing, solutions is something which is either impossible or
 bad for Django users.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/19904#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to