Martin Aspeli wrote:
Derek Richardson-2 wrote:
Benji York wrote:
Hmmm, to do that I have to be able to annotate an annotation, right? As
the feed is an annotation and that is where I want to store the UUIDs. I
tried this tonight and was unable to make it work - I got the following:
Derek Richardson wrote:
The specific case is uuids for atom feed entries. We have annotations
representing feeds and I would like my uuid utility to be local to the
feed annotation, thus recording and making available uuids only for
entries in that feed.
How about a multi-adapter from content and feed to UUID?
There's no reason why you can't mark an object that you fish out of an
annotation with IAttributeAnnotatable and then annotate that. However, this
feels suspiciously like you're asking the wrong kind question. :)
Can you explain (a) what you are trying to store (what is a "feed" in this
case? is it just feed-specific metadata? or an actual list of items rendered
to RDF?) and (b) what you need UUIDs for and (c) when you need to use the
Yes, it does feel like I'm going about this the wrong way.
a - The "feed" is actually just configuration metadata - whether the
feed is enabled, whether it is recursive, what its display name is, etc.
The actual feed document is not stored - it is simply rendered
dynamically when requested, based on the metadata and the existent
content items. The "feed" is an annotation on a container; at the
current time, only folders are feeds and only contained files are feed
b - In the Atom syndication format, UUIDs are necessary for two things.
One, the overall feed has a UUID. This is easy - I'm storing them in a
site-local named utility, indexed by the feed annotation object. Two,
each entry in a feed has a UUID. A content item that is an entry (a
file, in the current case) can, however, be in multiple feeds and needs
a different UUID in each. Thus, I need to be able to look up UUIDs by
the content object that will be rendered as a feed entry and look them
up relative to the feed, rather than globally.
c - I use the UUIDs only when rendering the feed, looking them up by
object and sending them to the client embedded in the feed document.
They are used for no other purpose.
So, my situation is that I've written my nifty uuid utility based on
intid and I want to reuse it for feed entry UUID lookup. I can't use
unnamed utilities because I may be accessing different uuid utilities
for entries from the same place in the tree. It occurs to me that I
could make them named utilities local to the object underlying the entry
and look them up by the feed UUID they correspond to, but, in my
understanding, that would require littering sites all over the place,
which seems like bad citizenship. So, I thought I'd just attach the
utility to the "feed" (remember, metadata), so that I can access it
through an adapter. Benji's short post gave me this idea. An alternative
is perhaps that I can just directly use the uuid utility class from the
"feed" class and avoid the annotations but have the same effect. In
fact, since the UUID lookup is an integral part of the feed and not just
an after-thought, this might indeed be more appropriate (and simpler)
than the annotation. Both these approaches that I favor (annotations and
direct usage) tightly couple the "feed" to the utility implementation,
which is unfortunate if I want to swap in another uuid utility
implementation (and, from what I've heard, this will be likely when I
backport to Five).
I hope this additional background makes things clearer.
Zope3-users mailing list