Re: [Zope3-Users] Wrong contained type - why?
Am Donnerstag, 26. April 2007 18:50 schrieb Rupert Redington: Hermann Himmelbauer wrote: Hi, As already mentioned before, I use interfaces that contain lists of other interfaces via the following syntax: emails = List(value_type=Object(schema=IEmail)) In my formlib-based class, I have use the following, so that the widgets are displayed correctly: email_widget = CustomWidgetFactory(ObjectWidget,Email) emails_widget = CustomWidgetFactory(ListSequenceWidget, subwidget=email_widget) and in the form.Form based class: form_fields['emails'].custom_widget = emails_widget The widgets are displayed perfectly, but when I try to update the data, the validation fails with the following error: Wrong contained type Well, I found the error myself - and it was very silly, therefore I did not post a solution: My class which implemented the interface, was declared twice, the second overwrote the first one and missed the implements() statement. So the very simple problem was that my object did not implement the interface. It's still my big problem that I need a long, long time to decipher various errors thrown by Zope3. In this special case I had to look through the formlib/schema source code, which is not easily understandable to me due to the interface/adapter patterns, which still leave me puzzled in various cases... Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Utility Local to an Annotation?
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? Martin -- View this message in context: http://www.nabble.com/Utility-Local-to-an-Annotation--tf3646832.html#a10217406 Sent from the Zope3 - users mailing list archive at Nabble.com. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Time for a Decimal field type in zope.schema?
Hi, Did the inclusion of Darryl's code ever get off the ground? I can't find a Decimal in zope.schema in Zope3.3.1 ... Regards, Adam Marius Gedminas wrote: On Thu, 31 Aug 2006 20:29:49 +0700 Darryl Cousins [EMAIL PROTECTED] wrote: On Thu, 2006-08-31 at 15:07 +0300, Marius Gedminas wrote: I am going to work on this today. For what it may be worth, a Decimal field: Code: http://projects.treefernwebservices.co.nz/tfws.org.nz/file/trunk/src/tfws/field/field.py Doctest: http://www.tfws.org.nz/tfws.field.README.html Looks nice. Would you consider contributing it for the inclusion into the Zope 3 core? (I see that it is already licenced under the ZPL, but I do not think I can just commit it into the Zope 3 repository under a different name.) I am attaching the diff showing my current working version, which mirrors the existing zope.schema.Float field more closely. As far as I can tell your field/widget is better. The only thing I do not see is a registration for a IDisplayWidget. Marius Gedminas ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Utility Local to an Annotation?
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 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Utility Local to an Annotation?
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 items. 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 constructs XML? 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? 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. 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 annotation - You generate feed item UUIDs on the fly from a hash/concatenation of the feed UUID and the generic object UUID Martin -- View this message in context: http://www.nabble.com/Utility-Local-to-an-Annotation--tf3646832.html#a10221944 Sent from the Zope3 - users mailing list archive at Nabble.com. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Utility Local to an Annotation?
On 4/27/07, Martin Aspeli [EMAIL PROTECTED] wrote: 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 annotation - You generate feed item UUIDs on the fly from a hash/concatenation of the feed UUID and the generic object UUID if you are generating UUID's based on the feed-specific UUID and a unique identifier for the object, you could just use the already present intid.. -- Martijn Pieters ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Utility Local to an Annotation?
Martin Aspeli wrote: 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 items. 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 constructs XML? Yes. 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? Hand the utility a feed annotation, get back a uuid for the feed. Also, is this UUID not just another aspect of feed metadata and thus a candidate for the container annotation? This was the original plan, but I was convinced to go with the more generalized solution of a uuid utility. I guess I can cache it in the container annotation, but that's an optimization and tangential to this discussion. 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. 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. I considered this. I have a certain understanding of what I'm doing that precludes the combinatorial UUID approach, but no one I talk to seems to grasp it, so I think I will air it here so we can discuss it. I am using RFC 4122 type 1 UUIDs. These are (practically) guaranteed universally unique, as they are based on spatial (MAC address) and temporal (CPU clock time) location. They have safeguards built in for things like multiple CPUs and resetting the CPU clock. However, they are only (practically) guaranteed universally unique if *everyone* follows the same algorithm. If you use a different algorithm for computing your UUIDs, then they may collide with my RFC 4122 ones, since your algorithm doesn't compute them the same way and thus may use different, supposedly unique information included in a different way that results in the same UUID that I generate. Highly unlikely, but vastly more likely than if we all follow the RFC. Thus, to me, part of being a good citizen of the UUID world is to follow the exact RFC 4122 algorithm, so we can all get along without collisions. There is no provision in RFC 4122 for combining two UUIDs to generate a third, still unique, UUID. So, in my mind, combining two UUIDs, by whatever method, results in a relative UID, not a UUID. Granted, I live in a fantasy world where everyone plays by the same RFC 4122 rules. Still, it's a nice world and I want to do what I can to encourage others to join me in it. So, I want to generate strictly-compliant RFC 4122 UUIDs for use in my product (and my utility makes it easy for others to use them elsewhere in Zope). Thus I take the hard road, here. Is there a flaw in my reasoning? 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. Right, you can still assign one (or more) UUIDs to any content object, if you have a use case. My UUID is for the (dynamically generated) feed item. The uuid utility is perfectly general and will let you assign a UUID to any object that can be adapted to KeyReference (or perhaps, in Zope2, any object that is usable by the intid utility). 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
Re: [Zope3-Users] Time for a Decimal field type in zope.schema?
Hi, No I don't know that it did. I wasn't at time a contributor to Zope. I am now however so I have no excuse. http://projects.treefernwebservices.co.nz/tfws.org.nz/file/trunk/src/tfws/field/README.txt Best regards, Darryl On Fri, 2007-04-27 at 20:37 +0800, Adam Summers wrote: Hi, Did the inclusion of Darryl's code ever get off the ground? I can't find a Decimal in zope.schema in Zope3.3.1 ... Regards, Adam Marius Gedminas wrote: On Thu, 31 Aug 2006 20:29:49 +0700 Darryl Cousins [EMAIL PROTECTED] wrote: On Thu, 2006-08-31 at 15:07 +0300, Marius Gedminas wrote: I am going to work on this today. For what it may be worth, a Decimal field: Code: http://projects.treefernwebservices.co.nz/tfws.org.nz/file/trunk/src/tfws/field/field.py Doctest: http://www.tfws.org.nz/tfws.field.README.html Looks nice. Would you consider contributing it for the inclusion into the Zope 3 core? (I see that it is already licenced under the ZPL, but I do not think I can just commit it into the Zope 3 repository under a different name.) I am attaching the diff showing my current working version, which mirrors the existing zope.schema.Float field more closely. As far as I can tell your field/widget is better. The only thing I do not see is a registration for a IDisplayWidget. Marius Gedminas ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
