Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Hi Tim. Unfortunately I didn't follow the discussion lately, so may be the problem is no more, but... I just committed a fix for zope.schema's ValidationError that makes its repr output more sensible. I'd like community to review those changes and say if they're okay, because changing exception formatting syntax will affect doctest so they should be adapted to new style. But I think it's better to adapt the doctests than to make debugging difficulties for our users, right? :) About your problem, here's the minimal failing example. from zope.interface import Interface, implements from zope.schema import Field, Object, Int from zope.schema.interfaces import IField from zope.schema.fieldproperty import FieldProperty class IObjectId(IField): value = Int() class ObjectId(Field): implements(IObjectId) value = FieldProperty(IObjectId['value']) class IObjectRef(Interface): oid = Object(IObjectId) class ObjectRef(object): implements(IField) oid = FieldProperty(IObjectRef['oid']) oid = ObjectId() oid.value = 3 ref = ObjectRef() ref.oid = oid Basically, it fails validation because the IField interface defines some attributes (like default and missing_value) that are not set in the Field base class and neither in ObjectId. So the exceptions are really RequiredMissing. But the general problem is still that you are misusing Field class as base for your not-fieldy class. It defines specific functionality for describing interface schemas and can be treated specially by other components. If all you need is its "title" and "description" fields, just define a base interface and implementation like: class IItem(Interface): title = TextLine(title=u'Title', required=True) description = Text(title=u'Description', required=False) class Item(Persistent): implements(IItem) title = FieldProperty(IItem['title']) description = FieldProperty(IItem['description']) ...and use them as base for your objects. Hope this helps. -- WBR, Dan Korostelev ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] BOUNTY! was: Next Step to Bug Resolution???
On Thu, 2008-12-18 at 13:00 -0200, Tim Cook wrote: > This issue is such a huge frustration for me that I am offering a bounty > of 100USD out of my personal pocket to the first person that solves the > issue, gets it committed to a published zope.schema egg and included in > the standard Grok distribution. > > It seems to me to be a reasonable (though not extravagant) amount since > most of the trouble shooting has already been done. Hi All, I want to change the conditions of this offer. Over the past several days there have been too many people to mention help me both publicly and privately with this issue in various ways. Mostly in patience and education. I would like to donate this small amount to the Python Foundation in the name of all professional Zope developers. Assuming no large outcry in the next few days this is where the 100 bucks will go. Thanks, Tim signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Thanks All, On Fri, 2009-01-16 at 21:55 +0100, Carsten Senger wrote: > > Sure you can have specialized fields that subclass from Field, TextLine, > or another base class. E.g. RegistrationNumber(TextLine) that takes care > to validate the input for a special format. But you use them in an > interface class, not the class that implements the interface. > Okay. I got this down now. I still have a problem with understanding the use cases for using attribute=Object(schema=IMySchema ... But now all of the docs may make mmore sense with all I've leearned to past few days. Cheers, Tim signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Hi Shane, On Tue, 2009-01-13 at 14:10 -0700, Shane Hathaway wrote: > Sorry, but the patch doesn't make any sense. Your version of > _validate_fields quietly skips validation entirely by default. First of all that is why I asked for others to look at it. :-) But I DID test it by inserting an incorrect schema and it did throw the correct error. I think it was the ShemaNotImplemented error. This was a few weeks ago but I can repeat it if needed. As I explained before; when one schema is checked by _validate_fields then all is well. The parameter 'errors' is None. Then errors is set to an empty list and any possible error msgs are appended. BUT when a schema has to check another schema because they are chained. 'errors' is already an empty list but even though the parameter errors is None a new list is appended to the first pass errors. This creates the msg WrongContainedType: [, []] because it IS a WrongContainedType because there is an empty list inside the original list. 'errors' is returned from _validate_fields back to the _validate method of the Object class where it is simply tested to see if it is empty. On this second pass it ISN't empty. It has another list inside so it fails the truth test and incorrectly throws an error. > Look at the __repr__ method of the ValidationError class in the > _bootstrapinterfaces.py module of the zope.schema package. This method > was designed to generate short error messages, but in your case it > appears to be truncating the error messages altogether. I would start > by changing that particular __repr__() method to: > > def __repr__(self): > return '%s(%s)' % (self.__class__.__name__, repr(self.args)) > > This version prefers verbosity. At a minimum, I hope this version of > __repr__ will change the bizarre message > "zope.schema.interfaces.WrongContainedType: [, []]" into something legible. It is more verbose. But I'm afraid it exhibits the same behavior as described above. Here are the results: in _validate raise WrongContainedType(errors) WrongContainedType: [RequiredMissing(()), WrongContainedType(([RequiredMissing(())],))] Note the empty parens. Now if I introduce bad code I get: in _validate raise WrongContainedType(errors) WrongContainedType: [RequiredMissing(()), SchemaNotProvided(())] SchemaNotProvided is correct. Though there isn't much else to go on but the full traceback points me to the right place. *** Shane, I think that so much of this is no longer useful. Right not now I'll go back and read all the obscure documentation (for the upteenth time) and see if it makes more sense now. I am very confused about thee use cases between creating Fields and using the Object(schema=Ischema) approach. Thanks for your help. --Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Hi there, On Fri, Jan 16, 2009 at 7:02 PM, Tim Cook wrote: > Thanks for all the assistance. > > On Fri, 2009-01-16 at 18:05 +0100, Martijn Faassen wrote: > >> Yes, you do create new schema fields by subclassing from Field. >> >> It's just that we saw you putting a field not in a schema but in what >> looked like a concrete object. > > This has given me a BIG pause while I'm working on a simpler example. > It may actually solve the problem. > Are you saying that in order to create a Field that can be used as an > attribute of another class; I should define it in an interface and ONLY > in an interface? You should define a field as a subclass of Field (or of some more specific Field). When you want to actually use the field you created, you can only do so in an interface: class MyField(Field): pass class IMySchema(Interface): a = MyField(...) You cannot store fields on concrete objects. You must have an attribute on the concrete object that implements IMySchema that is named the same as the field and is of the format defined by the field (thus, a unicode string for a schema.Text field, and a list for a schema.List field). Regards, Martijn ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Thanks for all the assistance. On Fri, 2009-01-16 at 18:05 +0100, Martijn Faassen wrote: > Yes, you do create new schema fields by subclassing from Field. > > It's just that we saw you putting a field not in a schema but in what > looked like a concrete object. This has given me a BIG pause while I'm working on a simpler example. It may actually solve the problem. Are you saying that in order to create a Field that can be used as an attribute of another class; I should define it in an interface and ONLY in an interface? Such like pseudo: import Field class IAbc(Interface) myNewField = Field( and then when I need to use it in a class, simply state that that class implements(IAbc)? If this is true I have a two month hard core re-factoring to do. Cheers, Tim > Perhaps we were wrong in reading your > code, and this is one reason why you should come up with a minimum > example that demonstrates the problem and only that, without a lot of > distracting code surrounding it. You're the best suited person to > actually create a minimum example. Thanks again. Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Hey, >> To debug this >> problem, a developer will need the smallest possible example of code >> that demonstrates the problem. That means, I take it, just 2 schemas >> and a single form. Describe briefly what you expect to happen and what >> in fact happens. If that example can be done *without* inheriting from >> Field that'd be good, as it is true that Field is only to be used >> inside a schema definition and once someone sees that we'll conclude >> that's the cause of the problem even though it might not be. > > It is interesting that in table 4.1 of Philipp W's book it specifically > states that Field is the base class for all other fields. So how does > one build fields that are noot part of the standard zope.schema? Yes, you do create new schema fields by subclassing from Field. It's just that we saw you putting a field not in a schema but in what looked like a concrete object. Perhaps we were wrong in reading your code, and this is one reason why you should come up with a minimum example that demonstrates the problem and only that, without a lot of distracting code surrounding it. You're the best suited person to actually create a minimum example. Regards, Martijn ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [RFC] Merging zope3-users list with z...@zope.org list
Andreas Jung wrote: > Thoughts? +1, they already end up in the same IMAP folder for me... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
On Fri, 2009-01-16 at 15:55 +0100, Martijn Faassen wrote: > I don't think a wiki page with a chronicle is necessary or even > helpful; you need to give us the information necessary to find the > bug, but no distracting surrounding information. Okay. > To debug this > problem, a developer will need the smallest possible example of code > that demonstrates the problem. That means, I take it, just 2 schemas > and a single form. Describe briefly what you expect to happen and what > in fact happens. If that example can be done *without* inheriting from > Field that'd be good, as it is true that Field is only to be used > inside a schema definition and once someone sees that we'll conclude > that's the cause of the problem even though it might not be. It is interesting that in table 4.1 of Philipp W's book it specifically states that Field is the base class for all other fields. So how does one build fields that are noot part of the standard zope.schema? > > Once we have the example someone can either debug the problem, or tell > you what you're trying to do isn't the right way to do it. > Thanks, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** <> signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
Hey, On Fri, Jan 16, 2009 at 11:37 AM, Tim Cook wrote: > On Mon, 2009-01-12 at 22:05 +0100, Martijn Faassen wrote: > >> Okay, I'll take another look then and look at ObjectRef. Ah, yes, Dan >> pointed out to you that you are using a zope.schema.Field in a class >> instead of in a schema (an interface). That isn't right, and since the >> direct use of that causes an error, that looks suspicious. Whether it is >> the cause of the bug or not I do not know. > > Thanks to all for the help. > I will put together a wiki page that chronicles and explains the entire > issue and process of getting here. Along with the simplest example I can > come up with. I don't think a wiki page with a chronicle is necessary or even helpful; you need to give us the information necessary to find the bug, but no distracting surrounding information. To debug this problem, a developer will need the smallest possible example of code that demonstrates the problem. That means, I take it, just 2 schemas and a single form. Describe briefly what you expect to happen and what in fact happens. If that example can be done *without* inheriting from Field that'd be good, as it is true that Field is only to be used inside a schema definition and once someone sees that we'll conclude that's the cause of the problem even though it might not be. Once we have the example someone can either debug the problem, or tell you what you're trying to do isn't the right way to do it. Regards, Martijn ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] [Zope-dev] Next Step to Bug Resolution???
On Mon, 2009-01-12 at 22:05 +0100, Martijn Faassen wrote: > Okay, I'll take another look then and look at ObjectRef. Ah, yes, Dan > pointed out to you that you are using a zope.schema.Field in a class > instead of in a schema (an interface). That isn't right, and since the > direct use of that causes an error, that looks suspicious. Whether it is > the cause of the bug or not I do not know. Thanks to all for the help. I will put together a wiki page that chronicles and explains the entire issue and process of getting here. Along with the simplest example I can come up with. I'm still a little confused about why using Field as a base class is wrong. I know that it wasn't it's original purpose but here is the situation. I originally inherited from 'object' in my base classes and from Interface in their associated interfaces. But, because many of the base classes (and their schemas) are required to define attributes of other classes. I found that I did not have the meta-data attributes such as required, default, etc for those schemas to represent the attributes in the latter schemas. So I chose to inherit from IField and Field in my bases so that I inherited. Now maybe there is a MUCH more appropriate way to build these OSHIP base classes than inheriting from Field. But in mid-2007 I searched hi and lo and asked on the mailing lists and still do not have a better solution. So if someone can tell me where I can find the documentation/examples for building your own schemas that will be validated then I'll re-factor the entire application to make it right. Cheers, Tim <> signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
