Re: [Zope-dev] zope.globalrequest?
Chris Withers wrote at 2009-1-16 17:00 +: > ... >Personally, I've always seen zope.* as being usable on their own or with >either Zope 2 or Zope 3. It seems this package is only usefully >targetted at zope2 I am not so sure. Accessing the request in a simple standard way may be useful whenever Zope is used as a web application server -- whether it is Zope 2 or Zope 3. > so a zope2.* namespace seems perfect. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17.01.2009 8:39 Uhr, Dieter Maurer wrote: > Hanno Schlichting wrote at 2009-1-16 10:14 +0100: >> Christian Theune wrote: >>> I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder >>> about it. IMHO this implements an anti-pattern in an official way >>> without a warning that this needs to be handled with care. >> The discussion for this happened on the plone-dev mailing list. The >> reasoning for the functionality is to provide a clean way to get to the >> request, without relying on Acquisition. Storing the request in a thread >> local is similar to the way other web-frameworks handle this. > > In addition, this is how the global Zope "site" is handled. > > It is good to be able to access both "site" and "request" in > a standard way. And it similiar accessing the current transaction using import transaction tx = transaction.get() So: +1 Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAklxjIIACgkQCJIWIbr9KYwHdwCfWIh4ofZxycUGq+Zk8F/pVuR0 MwgAnRJjI9P/nfh+KXtZvKjkvscdOHyM =TlB2 -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. & Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hanno Schlichting wrote at 2009-1-16 10:14 +0100: >Christian Theune wrote: >> I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder >> about it. IMHO this implements an anti-pattern in an official way >> without a warning that this needs to be handled with care. > >The discussion for this happened on the plone-dev mailing list. The >reasoning for the functionality is to provide a clean way to get to the >request, without relying on Acquisition. Storing the request in a thread >local is similar to the way other web-frameworks handle this. In addition, this is how the global Zope "site" is handled. It is good to be able to access both "site" and "request" in a standard way. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Christian Theune wrote at 2009-1-16 09:06 +0100: >I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder >about it. IMHO this implements an anti-pattern in an official way >without a warning that this needs to be handled with care. IMHO, it is not an anti-pattern: We have a global "site" why should we not have a global request? When Zope is used as a Web Application Server, it is quite natural to expect a request. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Benji York wrote: >> And what about zope.agxassociation, zope.bforest, zope.bobo, >> zope.generic, zope.ucol, zope.wfmc and zope.xmlpickle to name a few of >> the more than 30 packages already in the zope.* namespace which are >> neither part of any Zope release nor are likely to ever be? > > Some of those were past mistakes. Let's not repeat them. But you will repeat them. :) There's a chicken and egg problem here. Renaming packages is painful and penalises early adopters. However, you often don't know whether a package is going to be good (or maintained or just plain useful) until it's been implemented and tested in real life. To me, means "by the people of", i.e. zope.* means "by the people of the Zope community", or what not. A package written for the Zope core framework, by the Zope people, discussed on the Zope dev list belongs in this namespace. A good rule of thumb is "where is it discussed". If I have a problem with a zope.* package, I'd look at zope3-user or zope-dev. For z3c.* I'd hesitate to use zope-dev. The same goes for plone.* (plone-dev) or collective.* (product-developers). This certainly isn't perfect, though. There's a plone.* package in the Zope svn for possible inclusion in CMF one day; Plone ships with collective.*, borg.*, and archetypes.* packages. But really, the main point of namespaces is just to avoid naming collisions and make things easier to find. Let's not get *too* hung up on them. zope.globalrequest is probably fine. What matters is whether people actually use it, and whether it's maintained, covered by adequate tests or so on. No-one's going to go look at all zope.* packages and try to install them. They're going to install of a KGS or release and look for things in the documentation. However, my preference would've been z3c.globalrequest, since it's really a "community add-on" and wasn't really created as a proper part of Zope or discussed in the context of that. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Christian Theune wrote: > I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder > about it. IMHO this implements an anti-pattern in an official way > without a warning that this needs to be handled with care. First of all, I actually quite like this pattern. It's commonly used in other frameworks, e.g. Pylons, where the request is a pseudo-global. The utility pattern that Robert suggested would also work, though it'd be harder to implement I think. Secondly, though, I think this is a poor choice of namespacing. Namespaces ought to say something about who the package is controlled by. zope.* implies the package is controlled by the Zope project. I didn't see any discussion about this, so at best it seems like a bit of "namespace creep". Now, I understand that the intention was to make this easier to swallow should we want to include it in the future. That's certainly a sensible thing to think about, but since this package seems to have taken the Zope maintainers a bit by surprise, it would've been better to either release it under a different namespace with different connotations, or at least discuss its merits and naming here before making the release. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Stephan Richter wrote: > Then let's just mention its intended use in Zope 2/Plone in the documentation > and go on with life. i've just added such a note and made a fresh release — http://pypi.python.org/pypi/zope.globalrequest/1.0a2 best regards, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1.7 released! -- http://plone.org/products/plone/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope3-Users] Next Step to Bug Resolution???
Dan Korostelev wrote: > 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. +1. The output I see in the checkin is much more readable to my eyes. http://mail.zope.org/pipermail/checkins/2009-January/028856.html Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope3-Users] 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Next Step to Bug Resolution???
Hi Tim, Tim Cook schrieb: > 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)? that's what Dan Korostelev said early in the thread: Use the Field only in a schema definition. You define your schema in an interface class. The interface class describes the interface (fields, attributes, methods) that a class implements. from zope.interface import Interface, implements from zope.schema import TextLine class IMyTitleSchema(Interface): title = TextLine(...) class MyTitleClass(object or some other baseclass): implements(IMyTitleSchema) title = u"" The interface tells other components, e.g. forms: An object instanciated from MyTitleClass has an attribute 'title', and title is a TextLine. So a form can render the correct widget. Other components do other things with this information, like validation when the title attribute is written. You never use a schema field in something other than an interface class. Don't do: class MyTitleClass(...): ... title = TextLine(...) obj = MyTitleClass() 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. ..Carsten ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
On Fri, Jan 16, 2009 at 3:06 PM, Hanno Schlichting wrote: > Jens Vagelpohl wrote: >> Even though there is no official "dictator" for each of those common >> namespaces like zope, z3c, plone, archetypes, etc I do see value in at >> least attempting to be careful when choosing the namespace. Agreed. > And what about zope.agxassociation, zope.bforest, zope.bobo, > zope.generic, zope.ucol, zope.wfmc and zope.xmlpickle to name a few of > the more than 30 packages already in the zope.* namespace which are > neither part of any Zope release nor are likely to ever be? Some of those were past mistakes. Let's not repeat them. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Jens Vagelpohl wrote: > On Jan 16, 2009, at 18:25 , Hanno Schlichting wrote: > >> The concept of >> giving SVN repositories any kind of quality level aspect failed in the >> same way. Dependencies are specified in the setup.py and egg metadata. >> Quality is judged by who has written some code, number of tests, test >> coverage, amount of releases and so on. > > This is partly right, but one aspect is missing. Developers who know > these metrics (tests, coverage, release history) can apply them, > correct. But non-developers don't really have anything to go by but > the package name, title and description. That's how they end up > incorporating bad packages with disappointing results. If you don't know anything about cars and just buy one by the sound of the name it has, that is a poor way of choosing. You get professional help or ask someone whom you trust for advice. If you don't know how to choose an open-source software package, the same applies. Package names are labels that don't mean anything, in the same way most other labels don't mean anything. We tried to give them meaning at some point, but that attempt has failed. > Even though there is no official "dictator" for each of those common > namespaces like zope, z3c, plone, archetypes, etc I do see value in at > least attempting to be careful when choosing the namespace. The choice > of namespace probably does impart some kind of feeling of quality > level, and also of sensible grouping. Personal example: for me the > "zope" namespace sounds like a place where only those packages land > that are actually part of Zope 2 as delivered at that point in time. > "z3c" is for community-contributed add-ons, "plone" and "archetypes" > are related to Plone and Archetypes. And what about zope.agxassociation, zope.bforest, zope.bobo, zope.generic, zope.ucol, zope.wfmc and zope.xmlpickle to name a few of the more than 30 packages already in the zope.* namespace which are neither part of any Zope release nor are likely to ever be? Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
On Friday 16 January 2009, Hanno Schlichting wrote: > Christian Theune wrote: > > I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder > > about it. IMHO this implements an anti-pattern in an official way > > without a warning that this needs to be handled with care. > > The discussion for this happened on the plone-dev mailing list. The > reasoning for the functionality is to provide a clean way to get to the > request, without relying on Acquisition. Storing the request in a thread > local is similar to the way other web-frameworks handle this. Then let's just mention its intended use in Zope 2/Plone in the documentation and go on with life. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
On Friday 16 January 2009, Andreas Jung wrote: > On 16.01.2009 15:51 Uhr, Chris Withers wrote: > > Hanno Schlichting wrote: > >> Community" in its entirety. Inventing a zope2 or z2c namespace is a poor > >> choice. > > > > Why? That seems like the perfect namespace for this particular package... > > Namespaces are like dust and smoke. We already have enough (pointless) > namespaces. So let's stick with zope.* and z3c.* for Zope related packages. I agree. The z3c Namespace was created as a place where *all* Zope 2 independent extensions to Zope can go. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 16, 2009, at 18:25 , Hanno Schlichting wrote: > The concept of > giving SVN repositories any kind of quality level aspect failed in the > same way. Dependencies are specified in the setup.py and egg metadata. > Quality is judged by who has written some code, number of tests, test > coverage, amount of releases and so on. This is partly right, but one aspect is missing. Developers who know these metrics (tests, coverage, release history) can apply them, correct. But non-developers don't really have anything to go by but the package name, title and description. That's how they end up incorporating bad packages with disappointing results. Even though there is no official "dictator" for each of those common namespaces like zope, z3c, plone, archetypes, etc I do see value in at least attempting to be careful when choosing the namespace. The choice of namespace probably does impart some kind of feeling of quality level, and also of sensible grouping. Personal example: for me the "zope" namespace sounds like a place where only those packages land that are actually part of Zope 2 as delivered at that point in time. "z3c" is for community-contributed add-ons, "plone" and "archetypes" are related to Plone and Archetypes. I think the Plone community itself has a similar situation. Where's the line between plone.*, archetypes.* and collective.*? My ideal world would have one namespace where everyone could dump code, something like "collective" for the Plone community. If the package is considered high-quality and/or considered for the inclusion in Plone, as decided by the release manager(s), then the developer would be allowed to put it into the plone or archetypes namespace. Along these lines, I don't like to see globalrequest as a "zope" namespace package. Just my 2 cents. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklwy88ACgkQRAx5nvEhZLI3LgCfbSgIDJszqzvOGLxkxuBEfDXh uxoAoIJgV5MXLoJMUwkaUehcJ+LzKCup =PXy1 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Chris Withers wrote: > Andreas Jung wrote: >> Namespaces are like dust and smoke. We already have enough (pointless) >> namespaces. So let's stick with zope.* and z3c.* for Zope related packages. > > Why note merge those two into one then? Merging namespaces just causes work without any benefit. A namespace doesn't tell you anything about the code in question anymore. You have to have a dictator, who watches over the code that is published under *his* namespace and maintains a vision for what is appropriate for a particular namespace. We didn't have those dictators and we won't get them. For me a namespace has essentially no meaning today. It might give you a hint by whom or which community it was written, but that's about it. Ensuring code quality, dependency information or any kind of other metric in the name of a package is just the wrong place. The concept of giving SVN repositories any kind of quality level aspect failed in the same way. Dependencies are specified in the setup.py and egg metadata. Quality is judged by who has written some code, number of tests, test coverage, amount of releases and so on. > Personally, I've always seen zope.* as being usable on their own or with > either Zope 2 or Zope 3. It seems this package is only usefully > targetted at zope2, so a zope2.* namespace seems perfect. The package works fine with both Zope2 and Zope3. I thought the pattern it advocates might not be appealing to Zope3 users, but Robert has proven me wrong. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Andreas Jung wrote: > Namespaces are like dust and smoke. We already have enough (pointless) > namespaces. So let's stick with zope.* and z3c.* for Zope related packages. Why note merge those two into one then? Personally, I've always seen zope.* as being usable on their own or with either Zope 2 or Zope 3. It seems this package is only usefully targetted at zope2, so a zope2.* namespace seems perfect. As for too many namespaces, try the last line of import this ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Next Step to Bug Resolution???
Tim Cook wrote: > I would also like for you to explain just what it is about my "attitude" > that you find so offensive/problematic? As a general rule of thumb, anyone who posts with more than on exlamation mark is likely on the wrong track. Cross posting to several lists is also a bit of a no-no. Jumping up and down because someone won't look at your edge case problem unless you're offering that someone bucket loads of cash likewise ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.01.2009 15:51 Uhr, Chris Withers wrote: > Hanno Schlichting wrote: >> Community" in its entirety. Inventing a zope2 or z2c namespace is a poor >> choice. > > Why? That seems like the perfect namespace for this particular package... > Namespaces are like dust and smoke. We already have enough (pointless) namespaces. So let's stick with zope.* and z3c.* for Zope related packages. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAklwoDQACgkQCJIWIbr9KYzwOgCgm7O5QTn1v2V3i0IhnmreMLDX xZQAoLeHKVlmAEsZC9alygfh/WVy0QSu =nj7E -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. & Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hanno Schlichting wrote: > Community" in its entirety. Inventing a zope2 or z2c namespace is a poor > choice. Why? That seems like the perfect namespace for this particular package... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Jan 15 12:00:00 2009 UTC to Fri Jan 16 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Thu Jan 15 20:50:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010855.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Thu Jan 15 20:52:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010856.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Thu Jan 15 20:53:37 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010857.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Thu Jan 15 20:55:08 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010858.html Subject: OK : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Thu Jan 15 20:56:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010859.html Subject: OK : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Thu Jan 15 20:58:09 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010860.html Subject: OK : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Thu Jan 15 20:59:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010861.html Subject: OK : Zope[2.buildout]-trunk Python-2.5.2 : Linux From: Zope Tests Date: Thu Jan 15 21:01:09 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010862.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hanno Schlichting wrote:
> Christian Theune wrote:
>> I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder
>> about it. IMHO this implements an anti-pattern in an official way
>> without a warning that this needs to be handled with care.
>
> The discussion for this happened on the plone-dev mailing list. The
> reasoning for the functionality is to provide a clean way to get to the
> request, without relying on Acquisition. Storing the request in a thread
> local is similar to the way other web-frameworks handle this.
One thing I'll suggest if this gets used by Plone or Zope 2: in the unlikely
case that you'd want to call one Zope app from within another (impossible for
various other reasons right not, but maybe not forever), the thread local
structure would need to be a stack. Something like this:
import threading
class ThreadLocalRequestManager(threading.local):
def __init__(self):
self.stack = []
def push(self, request):
self.stack.append(request)
def pop(self):
if self.stack:
return self.stack.pop()
def get(self):
try:
return self.stack[-1]
except IndexError:
return None
def clear(self):
self.stack[:] = []
And then it would be used like so...
manager = ThreadLocalRequestManager()
try:
manager.push(request)
do stuff
finally:
manager.pop()
>
> The idea is to have this in default Plone and maybe suggest it for
> inclusion into Zope2 core. For Zope3 it is certainly not appropriate in
> general, as Zope3 has a clear abstraction of request dependent code.
It's probably inappropriate in Zope2 as well, but useful.
One of the reasons you can't run more than one Zope (2 or 3) application in the
same process is that the CA uses a global registry for its ZCML and the various
APIs (getUtility, getAdapter, etc) expect to be able to consult that single
registry, when you might need several. The only practical way out of this that
keeps old code running is to make a CA registry per application and push "the
right" one on to a thread local stack when a request comes in (and pop it off
when the request is finished). For this reason, it *might* even be more useful
to build a "context manager" that can manage more than just the request, e.g.
class Context(object):
def __init__(self, request, registry):
self.request = request
self.registry = registry
class ThreadLocalContextManager(threading.local):
def __init__(self):
self.stack = []
def push(self, context):
self.stack.append(context)
def pop(self):
if self.stack:
return self.stack.pop()
def get(self):
try:
return self.stack[-1]
except IndexError:
return global_context
def clear(self):
self.stack[:] = []
global_registry = getGlobalSiteManager()
global_context = Context(None, global_registry)
context_manager = ThreadLocalContextManager()
- C
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hi, Am Freitag, den 16.01.2009, 09:06 +0100 schrieb Christian Theune: > Hi, > > I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder > about it. IMHO this implements an anti-pattern >From application POV the request is a singleton, and the only kind of object which acts always in the same way in an Application Server. Since in Zope utilities represents singletons, the request might be provided global via an utility. >>> req = getUtility(IRequest) Some month ago i ran into the same problem to access the request out of another global utility. the fact that the request is not accessable global results then in ugly API signatures and difficult to re-use components. Robert ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Christian Theune wrote: > I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder > about it. IMHO this implements an anti-pattern in an official way > without a warning that this needs to be handled with care. The discussion for this happened on the plone-dev mailing list. The reasoning for the functionality is to provide a clean way to get to the request, without relying on Acquisition. Storing the request in a thread local is similar to the way other web-frameworks handle this. The idea is to have this in default Plone and maybe suggest it for inclusion into Zope2 core. For Zope3 it is certainly not appropriate in general, as Zope3 has a clear abstraction of request dependent code. Compared to the available options in Zope2/Plone this approach is seen as a more practical approach to deal with the (context.REQUEST) pattern. The original idea of migrating Zope2 to Zope3 approaches in the long term has failed in my opinion, as not being practically feasible. From a Plone perspective we now need to think about how to improve and enhance Zope2 on its own, which might divert from the direction that is appropriate for Zope3. The choice of the namespace is up for discussion. We have put a large amount of packages into the z3c namespace as of late, but I feel a package that is not meant to be used with Zope3 (though it can) isn't appropriate for the Zope3Community namespace. The next logical choice is to put it into the zope namespace which in my opinion stands for "Zope Community" in its entirety. Inventing a zope2 or z2c namespace is a poor choice. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.globalrequest?
Hi, I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder about it. IMHO this implements an anti-pattern in an official way without a warning that this needs to be handled with care. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
