Derek Richardson-2 wrote:
> 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
Okay, so the feed is really a view, which consults some annotations on a
container and then recursively looks for objects in that container and
> 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.
What do yuo mean "indexed by"?
Also, is this UUID not just another aspect of feed "metadata" and thus a
candidate for the container annotation?
> 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.
That sounds to me like you want a composite UUID - a UUID utility gives each
content item a UUID (which is not feed-specific, and stays in line with the
general concept of a content object UUID). The one you put in the feed is
the feed's UUID and the object's UUID are combined. You could possibly use
some kind of hash if you needed to.
> 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.
Still, the concept of a UUID of a content object ought to be separate from
and more general than your particular need for a feed item UUID.
> 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.
It does. I would not do this at all.
I think the cleanest design would be:
- You have a generic object UUID facility
- You make a UUID for a feed when you create it, and store it in the feed
- You generate feed item UUIDs on the fly from a hash/concatenation of the
feed UUID and the generic object UUID
View this message in context:
Sent from the Zope3 - users mailing list archive at Nabble.com.
Zope3-users mailing list