[Grok-dev] Re: Atom and RSS feeds in Grok

[Derek Richardson]

I apologize for dups or a new thread-id. Posting through gamne seems
to be failing atm.

Brandon Craig Rhodes wrote:
>
> Even if we agree that 3b is the way to go, and it's certainly the
> approach that I want to advocate in this email, how should it work
> behind the scenes?  It looks like it could work equally well two
> different ways: first, it could do the "two-storey" adapter scheme by
> registering itself as the IFeed adapter for its context, and then going
> and also registering named Atom and RSS2 adapters atop its context as
> well.  When the user went to view "herd/rss2", the view adapter would
> wake up, try to adapt its context to IFeed, and thus wake up the
> HerdFeed and call it to figure out the feed title and everything else.
> But this two-storey scheme really seems excessive to me, even though, as
> I have mentioned, it is currently the Vice way of doing things (at the
> moment; this whole experience leads me to want to make Vice simpler
> too!)  The alternative is for the HerdFeed in 3b to simply register
> *itself* as the view for "/atom" and "/rss", and have it dynamically
> select which template it uses to render itself by looking (how?) at what
> name it was summoned under.

I disagree. Currently, in Vice, there is one view that never changes
(well, three, one for each format, but this will go away soon). This
view adapts (IFeedable, IBrowserRequest). To make an object able to be
fed, you do two things:

1. Write an adapter from the object's class to IFeed
2. Provide IFeedable on the object

This way, the view contains what is the usually the *same* for all
requests for the feed, regardless of context, and the adapter
encapsulates everything that *varies* by the context. This is the
reason for the "two-storey" approach.

Your approach would require adding all the methods that currently live
on the adapter to the view, so that the view can render an object of a
class and so that it can be selectively overridden, to minimize
boilerplate. So, while in Vice currently, let's say:

MammothToIFeedAdapter(object):
    implements(IFeed)
    adapts(IMammoth)

    def title(self):
        return 'A title'

    ...

    def UID(self):
        return 'A unique identifier'


FeedView(...):
    ...view boilerplate...

You get:

MammothFeed(...):
    def title(self):
        return 'A title'

    ...

    def UID(self):
        return 'A unique identifier'

    ...view boilerplate...

Now, perhaps the view boilerplate lives on one superclass and is
simply inherited repeatedly, so you don't actually rewrite it. But I
object to it being there at all. I contend that your route results in
one class that is less cohesive and more tightly coupled than my two
class approach. It is better to separate the constant and varying than
to tramp the constant through every variation.

The clincher would be if someone wanted to change the view and use the
same IFeed-adapted objects. In your scenario, this would result in a
combinatorial explosion of views. In my scenario, it results in one
more view and zero more adapters.

> Anyone who has read this far, please provide feedback on which route I
> should try taking! :-)
>
> You will note that I have said nothing about how objects themselves
> become feed members.  This is because I consider it straightforward; the
> developer will simply grab the type he wants to syndicate and give it an
> IFeedItem adapter that makes it eligible to appear in a feed.  We could
> make them use grok.Adapter for this, but it would be more friendly to
> provide a "FeedItem" content type that gets grokked and registered for
> them:
>
>     # example of how a feed item gets prepared for the feed
>
>     class MammothItem(grok.FeedItem):
>         grok.context(Mammoth)
>         def update(self):
>             self.title = "The mammoth named %s" % self.context.name

This approach that you are taking with feed items is exactly what I am
contending should be done with the feed itself. To carry your feed
logic above to its logical conclusion, you would not have FeedItem
adapters either, but simply have a view that knows how to go from
objects to the information required to render an object as an item in
a feed. My position is consistent: adapters adapt objects of varying
interfaces to a single interface so that they can be used by a single
view.

Derek