Etria Lists

>  > I am curious: is the listing of entries limited to those with
>  > IPossibleWeblog marker?
>
>  In principle, no.  In practice, yes.  The IPossibleWeblog marker
>  interface is just there to make it easy for the UI layer to know if it
>  is possible to treat an object as a weblog.  I suppose it would be
>  possible to just try to adapt to IWeblog each time, but testing for
>  IPossibleWeblog.providedBy(context) should be cheaper than doing
>  IWeblog(context)... I would have thought.  <shrug />
>
>  Actually, now I'm confused about what your question is.  If you meant,
>  "is the listing of entries limited to those with IPossibleWeblogEntry
>  marker", then the answer is "yes".  The IWeblog adapter for folders,
>  when implementing things like getEntries, does a catalog search based on
>  object_provides=IPossibleWeblogEntry so that only subobjects that can be
>  adapted to IWeblogEntry are returned.  There could be all sorts of
>  arbitrary objects in a weblog-enhanced folder that we don't want to handle.
>

This is what I was asking, and I was pretty much getting at the idea
of not necessarily listing all contained objects in a weblog view,
just because we are using normal content.  I like that IPossibleWeblog
or something similar would allow us to mark types.

>  As a side point, this reminds me that one thing we need to do is arrange
>  for a recataloging of all instances of classes that are marked with
>  IPossibleWeblogEntry whenever we install QuillsEnabled.  Otherwise the
>  catalog search described above will not return (m)any objects.
>

+1

>
>  >> We could register our portlets for all IPossibleWeblogEntry objects and
>  >> then have the renderer crawl up the aq_chain looking for an object
>  >> implementing either IWeblog directly (as in the Quills case) or
>  >> IWeblogEnhanced (as in the QuillsEnabled case).  Somehow that feels a
>  >> bit heavy handed, although it may not actually come with performance
>  >> penalties as presumably zope's standard traversal mechanism will have
>  >> 'woken up' all parent objects.
>  >>
>  >
>  > Here's the ten dollar question: why don't the child objects inherit
>  > this portlet, as seems to be the default?
>
>  Not sure off the top of my head.  Perhaps they pick up portlets for
>  their type instead.
>

I believe there is a precedence order, but that parent, type, and
local context portlets display.  That said, I am not sure if all of
the parent portlets inherit, possibly depending on how they are
assigned.  You give me more info to go on for this below..

>
>  >> Another alternative is to mark the request object with an interface
>  >> during our custom traversal mechanism so that we know when we are
>  >> operating "inside" a weblog.
>  >>
>  >
>  > If I had a kitten in my lap, it would be scared. :-P
>
>  Actually, something like this has the added advantage of working even in
>  those cases where the IPossibleWeblogEntry objects are *not* contained
>  within the IWeblogEnhanced object.  One example of such a case might be
>  an adapter from ISmartFolder (or whatever it's called these days) to
>  IWeblog.
>

Hm.

>
>  > An idea I had is that instead of rendering the portlet for content
>  > objects with a given interface, we might simply attach the quills
>  > portlets to a container when weblog-ifying it.
>
>  This is essentially what we do.  We register an adapter from quills-ish
>  types to IPortletContext that makes the portlets machinery know about an
>  extra "interfaces" category (on top of portal_types, context, and the
>  other one I've forgotten).  We then register a bunch of portlets for
>  that interfaces category.
>

Understood.

>
>  >  This might nullify the
>  > ten dollar question above, but I am also concerned that it is a bit
>  > heavy handed.
>
>  Don't think so.  They are not persisted on an object-by-object basis,
>  but rather are registered on a site-wide basis per interface, which
>  seems ok to me.
>

Sorry, I was calling my proposed approach potentially heavy handed, not yours.

I see that yours is very simple and lightweight, driven by interfaces,
which I like. I am concerned that it may make more sense for some
portlets to be attached to the instance, so that they use existing
machinery to allow contained objects to inherit as Plone3 users are
learning to expect.  However, I can see some advantage of your request
marking idea, and I wonder if the 'interfaces' category behaviour
could possibly care about parent interface, or if that would even be a
good idea at all.

J

-- 
Justin Alan Ryan
Independent Interaction Architect
http://www.bitmonk.net/
* : +1-415-226-1199