Martin Aspeli wrote:
Derek Richardson-2 wrote:
Benji York wrote:
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?
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:
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 items.

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

Reply via email to