On Mon, Aug 3, 2009 at 8:37 PM, zellyn<[email protected]> wrote:
>
> [Hi folks. This is a re-post, now that 1.1 has been released.]
>
> Django's contrib.syndication app feels different from normal views,
> using a dictionary and dispatching by slug, then finding objects by
> splitting the rest of the URL into "bits".
>
> It takes surprisingly few changes to make Feeds respond as normal
> views: define the __call__ method on Feed objects.
>
> Here are the changes required (using pastry.se for its diffing
> capability): http://pastry.se/46009/#e46010
> And here's the output of `svn diff`: http://pastry.se/46016/
>
> Thoughts, comments, suggestions?
I completely agree that the feeds framework is due for a shakeup. On
my personal wish list in this area:
* Parameterized feeds. The 'bits' in a feed URL currently need to be
the trailing parts of a URL. That isn't always convenient - what if I
want /mystuff/(.*)/feed, not /mystuff/feed/(.*) ?
* Named urls. I should be able to reference a feed's URL (including
parameterized parts) using the {% url %} tag.
* Making individual feed views decoratable (e.g., for caching, or
Http Authentication)
On top of this, there is a general problem of backwards compatibility:
whatever changes are made, existing code can't break.
It looks like you might be heading down a similar path - although I'm
a little hazy on some of the details. It looks like there is some code
missing (at the very least, documentation on the purpose of
get_view_object, or at least an implementation of get_view_object to
use as a reference). However, from what I can make out, what you have
makes sense.
My one concern is the extent to which the "new" feeds interface will
contain legacy elements. Most notable is the need to provide a 'slug'
when constructing the feed instances. At the very least, it strikes me
that slug should be an optional argument, since it doesn't really make
much sense outside of the classic feed deployment view.
Regardless of any particular implementation issues, the basic idea
(cleaning up feed deployment) is certainly worth sticking on the v1.2
feature list. Open a ticket and add it to the feature page on the wiki
to make sure it gets considered when the time comes.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
