[Zope3-Users] Re: Utility Local to an Annotation?

[Derek Richardson]

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
> UUIDS?

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.

Thanks,

Derek