#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 dokterbob):
Perhaps the original ticket was not sufficiently clear:
1. The current API for (extending) Feeds is a real pain in the buttocks
and there is no common practise for doing so. Hence, a lot of apps which
actively use Feeds tend to write similar extension code or write their own
Feed views altogether. This is not DRY at all; this causes a lot of double
work both in terms of initial development as well as maintenance. Hence
the proposal could be read as: refactor the feeds API.
2. As jacob says, if we were to rewrite the Feeds API now it *might* make
sense to use generic CBV's. As both luke and jacob stress; there is not
much in common apart from the `as_view()` call as far as *usage* is
considered. However, especially with feeds, a very large part of the users
will want to extend the functionality and from an 'inner' API level having
a similar structure to the generic CBV's might make a lot of sense. Think
of passing in optional arguments to `as_view()` but also overriding
`get_queryset()`. Possible use cases include using view mixins for both
generic list views as well as feeds. Wait, let me say that again: *view
mixins*.
Perhaps a better description for this ticket would be: 'Refactor feeds
API'.
And then as description:
----
Currently the functionality and (internal) API for the feeds contrib is
spread out over a core module `django.utils.feedgenerator` and a contrib
module. The original purpose for this is unclear and it makes the API hard
to extend and adds code to the Django core which is actually only used by
the feeds contrib. Hence the proposal reads:
1. Factor the `feedgenerator` API out of `django.utils` and merge it into
the feeds contrib such that for extending a view only a single object
needs to be subclassed.
2. While refactoring, use applicable generic CBV base classes/mixins so as
the yield a common API and allow for the usage of common mixins between
feed and list-type views.
----
Let me know if the latter makes sense to you; I could open up another
ticket if you think it does (or perhaps we could update the exising ticket
as not to loose context - though I'm a mere contributor and don't seem to
be able to update the original ticket).
--
Ticket URL: <https://code.djangoproject.com/ticket/19904#comment:8>
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.
