[Grok-dev] what will syndication look like under Grok? Tell us!

[Brandon Craig Rhodes]

The author of a syndication system for Plone, Derek Richardson (whose
system is oddly named "Vice"), was discussing with me the idea of us
creating a "megrok.vice" that would allow Grok developers to easily
use his code for syndicating their content.

But in the course of our conversation, we uncovered some fairly
significant differences between how Grok has taught me to think about
customization, versus how Plone development has taught him to think,
so I wanted to ask here on the Grok list about the issue.

The essential question is: what kinds of things should get configured
in code, and what should get configured inside, in the object state
kept inside of the ZODB?

You see, when he talked about a "megrok.vice", I immediately imagined
something that would work like the XMLRPC and REST views/adapters we
already have, in which case defining, say, the ability of a Blog
object to present an RSS feed at its ".../rss" URL might look like:

    class EntryRSS(megrok.vice.RSSItem):
        """Presents a blog entry as an RSS item."""
        grok.context(BlogEntry)
        def update(self):
            self.title = self.context.metadata['title']
            self.link = self.url(self.context)
            self.description = self.context.content

    class BlogFeed(megrok.vice.RSSFeed):
        """Provide an .../rss view on every Blog object."""
        grok.context(Blog)
        grok.name('rss')

In the example I have imagined above, you just define an adapter
called an RSSEntry that explains how one of your Model types would
present itself as an item in an RSS feed, and then you create an
actual RSSView subclass that creates an '.../rss' view on each Blog
where people could read its contents rendered as an RSS document.

This example startled Derek, because it provides no way for a web site
manager to turn syndication on or off for each blog instance at
runtime.  In other words, Derek expected to see an indirection layer
that would let normal users to be presented with check-boxes and such
to (a) turn syndication on and off for each blog, and (b) perhaps
define different URLs and semantics for them.  For example, of three
Blog containers on a Plone site, maybe they would want:

  http://site/main/blog/rss - a recursive feed of everything under "blog"
  http://site/userblogs/brandon/rss - a feed that collects things 1 level deep
  http://site/project/blog/rss2 - for this Blog the RSS view name is different

In Plone, Derek defines a kind of "root" view for Vice that exists on
all objects, and then "/rss", "/atom", and so forth exist *under* that
basic view that's always "on".  By providing a View that works on all
objects, he can then allow custom URLs selecting user-crafted feeds at
the level beneath that.

Anyway: I don't know whether the above makes much sense, but I hope
that it gives enough of a sketch of two ways of doing things that you
Grok folks can give us some guidance.  Which of the following should
megrok.vice provide?

 (a) A simple way to items to be rigged up as feed entries, and then a
     way for container types to provide full feeds, where *both* are
     simply provided by creating subclasses of things like RSSEntry
     and RSSFeed whose "context" objects are the types we want to
     syndicate?

 (b) A way for the programmer to explain *how* objects and containers
     get suited up for RSS, but that leaves them *inactive* until a
     particular object is annotated at runtime as being something a
     site manager *wants* syndication turned on for?

My instinct was to start with (a), because it seemed to me (given my
limited experience) more "Grok-ish"; we like to define things in code
and then just have them work, without having to go into our admin
interface and turn syndication on for each container we might create.
But, for people building something like Plone, I can also see why they
would want user-settable check boxes on everything.

Which way is more in the spirit of Grok?

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon