Re: [Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
Johan Carlsson wrote: Anywhere I can read up on what's happening with this issue/bug? - The class attribute of the widget-directive can handle a custom factory or a widget class. - The __call__ method of custom widget factory (zope.app.form.CustomWidgetFactory) invokes collection, choice and regular fields correctly (respection specific signatures) - Custom widget sequence factory (zope.app.form.CustomSequenceWidgetFactory) is deprecated because it does not satisfy the IViewFactory interface. Use the CustomWidgetFactory instead. Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
Dominik Huber wrote: Johan Carlsson wrote: Anywhere I can read up on what's happening with this issue/bug? - The class attribute of the widget-directive can handle a custom factory or a widget class. - The __call__ method of custom widget factory (zope.app.form.CustomWidgetFactory) invokes collection, choice and regular fields correctly (respection specific signatures) - Custom widget sequence factory (zope.app.form.CustomSequenceWidgetFactory) is deprecated because it does not satisfy the IViewFactory interface. Use the CustomWidgetFactory instead. This is in the trunk right? /Johan -- Johan Carlsson Tel: + 46 8 31 24 94 Colliberty Mob: + 46 70 558 25 24 Torsgatan 72Email: [EMAIL PROTECTED] SE-113 37 STOCKHOLM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: CustomWidgetFactory and widgets having different __init__ signature
Johan Carlsson wrote: Dominik Huber wrote: Johan Carlsson wrote: Anywhere I can read up on what's happening with this issue/bug? - The class attribute of the widget-directive can handle a custom factory or a widget class. - The __call__ method of custom widget factory (zope.app.form.CustomWidgetFactory) invokes collection, choice and regular fields correctly (respection specific signatures) - Custom widget sequence factory (zope.app.form.CustomSequenceWidgetFactory) is deprecated because it does not satisfy the IViewFactory interface. Use the CustomWidgetFactory instead. This is in the trunk right? /Johan Yup. -- Dominik Huber Perse Engineering GmbH Jurastrasse 9a CH-5406 Baden E-Mail: [EMAIL PROTECTED] Telefon: ++41 56 534 7730 begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] unique intids rationale
Hi! what is the rationale between the unique integer ids utility and the usage policy? more specifically: why are newly added objects registered in *all* IntIds utilities? It does not make sense if the utility is registered locally. If they are local they should not be concerned with objects added elsewhere than outside their scope. can it be turned off in the application? regards /JM .../Zope3/src/zope/app/intid/__init__.py def addIntIdSubscriber(ob, event): A subscriber to ObjectAddedEvent Registers the object added in all unique id utilities and fires an event for the catalogs. utilities = tuple(zapi.getAllUtilitiesRegisteredFor(IIntIds)) if utilities: # assert that there are any utilites key = IKeyReference(ob, None) # Register only objects that adapt to key reference if key is not None: for utility in utilities: utility.register(key) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Gary Poster wrote: On Nov 21, 2005, at 12:29 PM, Jean-Marc Orliaguet wrote: There is another place where there seems to be two different patterns too: sometimes we have: import zope.schema name = zope.schema.TextLine(...) and sometimes: from zope.schema import TextLine name = TextLine(...) FWIW, a third is from zope import schema which I often do for zope.component, zope.interface, zope.event, and zope.schema. I'm not weighing in on the style issues. I like this third style option, import the last module, and then use the dot notation, and I tend to move towards this pattern in most of my code. Sometimes of course importing the one class is more convenient. Rarely do I use the full dot notation. The benefit of the third option is that it cuts down on your imports and keeps some namespace information in your code without having to do a lot of typing nonetheless. For cases like schema and for instance, hurry.query, there are cases where the same name in the module is referenced many times in the same file, and in that case I may be more inclined to import the name directly without any module prefix. I don't think using any of these patterns is a big style problem (I'm much less opinionated about this than about code in __init__.py); it's hard to recommend a single practice, so perhaps we shouldn't. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Martijn Faassen wrote: I don't think using any of these patterns is a big style problem (I'm much less opinionated about this than about code in __init__.py); it's hard to recommend a single practice, so perhaps we shouldn't. +1 Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: unique intids rationale
This has already been added to the bug collector : http://www.zope.org/Collectors/Zope3-dev/466 Jürgen Jean-Marc Orliaguet wrote: Hi! what is the rationale between the unique integer ids utility and the usage policy? more specifically: why are newly added objects registered in *all* IntIds utilities? It does not make sense if the utility is registered locally. If they are local they should not be concerned with objects added elsewhere than outside their scope. can it be turned off in the application? regards /JM .../Zope3/src/zope/app/intid/__init__.py def addIntIdSubscriber(ob, event): A subscriber to ObjectAddedEvent Registers the object added in all unique id utilities and fires an event for the catalogs. utilities = tuple(zapi.getAllUtilitiesRegisteredFor(IIntIds)) if utilities: # assert that there are any utilites key = IKeyReference(ob, None) # Register only objects that adapt to key reference if key is not None: for utility in utilities: utility.register(key) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: __init__.py interfaces.py guidelines?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Marc Orliaguet wrote: There is another place where there seems to be two different patterns too: sometimes we have: import zope.schema name = zope.schema.TextLine(...) and sometimes: from zope.schema import TextLine name = TextLine(...) any reason to use one or the other (speed, verbosity, avoiding circular imports, ...) ? I vastly prefer the second: it keeps the use points clearer, I don't know what you mean. Perhaps you are refering to extra clutter at point of use. I'm sympathetic to this, especially if something is used a lot. I generally find the point of use clearer with the full dotted name, or, for populat modules, like zope.component, zope.schema, etc: from zope import schema ... name = schema.TextLine(...) I think this is largely a matter of taste. ... It is also ever-so-slightly faster, as it avoids a name lookup at point-of-use. That optimization is the source of only downside of the practice: it makes monkey-patching harder, because the original binding gets copied. I generally only worry about the speed when something is going to be called a lot, as in a tight loop or in a very popular function. In cases like those, I do prefer to import the name locally. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Gary Poster wrote: On Nov 21, 2005, at 12:29 PM, Jean-Marc Orliaguet wrote: There is another place where there seems to be two different patterns too: sometimes we have: import zope.schema name = zope.schema.TextLine(...) and sometimes: from zope.schema import TextLine name = TextLine(...) FWIW, a third is from zope import schema which I often do for zope.component, zope.interface, zope.event, and zope.schema. I'm not weighing in on the style issues. FWIW: - For obscure things that are used only a few times in a module, and especially for things that are used only during module import, I prefer the first form. This makes the code easier to read because you don't have to refer to the imports. It also tends to make the imports shorter and easier to manage. - For popular modules like component, interface, and schema, I strongly prefer the thirs option because it keeps the imports simpler, and falls between the two extremes. A variation of the the third option that I also like for similar reasons as above occurs when importing sibling modules within the same package. For example, suppose we have modules foo and interfaces within mypackege. In foo, if I wanted to get to interfaces, I would use: from zope import interface from mypackage import interfaces class Foo: interface.implements(interfaces.IFoo) This gives us the same effect as if we had done a relative import of interfaces: import interfaces without breaking the no-relative-import rule. - I prefer the second form for well-known objects that are used a lot. For cases that fall between these extremes, I tend to prefer the first form. I think this is a matter of taste and art. I'm not very keen to legislate this. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] unique intids rationale
Jean-Marc Orliaguet wrote: Hi! what is the rationale between the unique integer ids utility and the usage policy? more specifically: why are newly added objects registered in *all* IntIds utilities? It does not make sense if the utility is registered locally. If they are local they should not be concerned with objects added elsewhere than outside their scope. can it be turned off in the application? Yes, by not registering the subscriber that does this registration. (We really need a way to override subscribers. Hopefully we'll get this in the next release cycle.) A common approach is to use one unique i utility for a system. This aproach works for lots of applications, vbut certainly not all. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: unique intids rationale
j.kartnaller wrote: This has already been added to the bug collector : http://www.zope.org/Collectors/Zope3-dev/466 Jürgen Jean-Marc Orliaguet wrote: Hi! what is the rationale between the unique integer ids utility and the usage policy? more specifically: why are newly added objects registered in *all* IntIds utilities? It does not make sense if the utility is registered locally. If they are local they should not be concerned with objects added elsewhere than outside their scope. can it be turned off in the application? regards /JM Hi! It seems to be another problem here, since local intids utilities behave like global ones - if I get the code correctly, the same objects are registered in *all* intids utilities. At some point this leads to race conditions, when objects have not yet been created or they get deleted, regards /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.testrecorder
We don't have the collective time right now to market this, but it's very cool so we thought someone might get some use out of it. Brian Lloyd has developed zope.testrecorder, a cross-browser (IE, Firefox, Safari) JavaScript app that records browser events (clicking, entering text, etc.) and test assertions (this text box should contain this text, this checkbox should be unchecked, etc.) and renders the captured events as either an HTML Selenium test or a doctest using zope.testbrowser. It can be installed as a product into Zope 2 or as a Python package in Zope 3. The rendering framework is pluggable and it's pretty easy to add new rendering options for other testing systems (twill, etc.). The testrecorder is currently in beta form, but is very handy, so if anyone wants to use/market/improve/add tests for it, go ahead. :) Get it via Subversion at svn://svn.zope.org/repos/main/zope.testrecorder/trunk -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Jim Fulton wrote at 2005-11-21 09:43 -0500: ... A Python convention is that a leading underscore indicates privateness. - what about import paths inside a same package: relative or absolute? from mypackage.interfaces import ISomeInterface or: from interfaces import ISomeInterface Absolute always. Until the Python import mechanism is fixed, *always* use absolute imports. But, this will make refactoring (moving modules around in the package hierarchy) more difficult. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.application.HTTPPublicationRequestFactory interprets text/xml requests as XML-RPC (was: [Zope] Hard-coded Content-type:text/xml as xmlrpc in Zope (2.8.1))
John Ziniti wrote at 2005-11-21 15:04 -0500:
...
Zope-2.8.1 now additionally has the zope.app.publication.
HTTPPublicationRequestFactory class, which also assumes
that text/xml means xmlrpc (in fact, it assumes that
anything that startswith('text/xml') is an xmlrpc call).
zope.app is part of Zope 3.
You should complain about this misfeature on zope3-dev@zope.org.
Definitely, there should not be a fixed (not configurable)
association between text/xml requests and XML-RPC
as text/xml can be interesting for the application and
for SOAP.
Not fixing old code which acts in strange hard-coded ways is
something I understand, but adding new code that also
acts that way seems like it is getting further away
from good :)
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.application.HTTPPublicationRequestFactory interprets text/xml requests as XML-RPC (was: [Zope] Hard-coded Content-type:text/xml as xmlrpc in Zope (2.8.1))
--On 22. November 2005 20:37:16 +0100 Dieter Maurer [EMAIL PROTECTED] wrote: You should complain about this misfeature on zope3-dev@zope.org. Definitely, there should not be a fixed (not configurable) association between text/xml requests and XML-RPC as text/xml can be interesting for the application and for SOAP. For Zope 3.2 publishers are pluggable and can be configure through ZCML. The registration is based on the request method and mime-type. -aj pgpxRnn3mdlXL.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
