Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 16:41, Martijn Faassen faas...@startifact.com wrote: As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass Yuck! That said, it would be easy to implement (haha) if people really want in together with @implemeter(IFoo) Which I have to say I prefer. If we do well we might all have this for Christmas. :) Time to clean up that branch of zope.interface I have, I see. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Chris McDonough wrote: Martijn Faassen wrote: [snip] So now that we've had some discussion and to exit the bikeshed phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible. I suggest we think to ourselves who the primary beneficiary of this goal is. I don't really disagree with anything you say here in absolute terms, but if the goal is increased adoption by new users, I think there are (relatively) more fundamental things that could be done to help. For this measure I'm not interested in increased adoption by new users. I just want to be able to have a more convenient way to express these things. So, my goal is to make life easier for myself (and hopefully others). In particular, I'd suggest we write real documentation for the current zope.component package. When I say real documentation, I mean something like this: http://docs.repoze.org/component/. Official docs for the package itself. Once you start writing documentation, obvious refactoring opportunities often fall out that are more important than adding another layer of abstraction. I think adding more abstraction without documenting the current system will not serve a goal of increasing adoption. I don't think there's much in the way of abstraction I'm proposing. It's an improvement of an API that's been bothering me for a long time (and this idea has floated around for a long time), influenced by the extensive experience have with this API. I'd be happy to see better documentation, and I'm sure that by writing better documentation further improvements will appear. Different topic, though. But as we're on that topic, I'll commit to writing better documentation for this package. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Are people okay with the proposed semantics? +1. Would people be okay with such an upgrade path? Any better ideas? I would start issuign DeprecationWarnings (yes, I know I'm their worst fan, but we can't keep BBB here, so warnings are appropriate) for positional defaults in 3.9.x. Good idea. Let's release a 3.9.x (or a 3.10) that does that as soon as possible. I think we should also document the don't call API better (pure lookup): there have been use cases for this feature (e.g., adapt to scalar / string) floating around for a *long* time now, unsupported. If that means accepting the zope.registry change Chris proposed, I'm fine with that. I'm not sure I understand how Chris' zope.registry change has something to do with this API, perhaps I missed something? I agree that we could document this API better though. Most importantly, any volunteers? I can help some with this. Perhaps we should start by fleshing it *really good docs* (not doctests) for zope.component 4.0, including careful notes about how to make existing code compatible with both 3.x and 4.x APIs. I'd be happy to help with this. I think that this work could be started in the trunk right away, as this documentation should be useful for 3.x as well, at least in terms of transitioning existing code. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Adam GROSZER wrote: I had a feeling that adapter lookup can be alone slowish with lots of registrations. We had a large project that was cut in half and the z3c.form UI, which is rather heavily adaptation based got a boost after that. Interesting. It'd be interesting to do some experiments with this. Could you perhaps look into writing some kind of stress-test script? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] split out zope.component mechanics into a separate package (was Re: improving the utility and adapter lookup APIs)
Chris McDonough wrote: [snip] It tries to address the following problem. Currently people seem to get wrapped around the axle and confused by the purpose of the ZCA, which currently implies at least two different things: - Machinery to perform complex registrations and lookups using interfaces in the form of a registry. - A global API that presents a view of the world: there are these things called utilities and adapters, and this API is how you do adaptation and utility lookup. These two things are conceptually distinct. It shouldn't be necessary to need to understand the concept of utility and adapter to use a registry. A registry is just machinery that uses interfaces as registration markers for the benefit of later arbitrary lookups, not necessarily just for finding utilities or finding and calling adapter factories. For instance, you might use the registry to register some callable that accepts *no* arguments with, say, two requires arguments. You shouldn't need to call this an adapter, because it's not one; you just want to register something and get it back when you ask nicely. Agreed, but isn't this registry in zope.interface already? I mean zope.interface.adapter.AdapterRegistry? I've used this for the not-really-adapting-as-I-don't-want-to-call in a library of mine recently (traject). You factored out the registry functionality, but there are still plenty of references to utilities in it, for instance. As far as I understand it that would be putting too much into zope.registry already? The API of a registry should be able to evolve separately from the API of its consumers (the global ZCA API is only one consumer). The current registry API permits the concepts of utility and adapter to bleed into the implementation, but this needn't be the case forever. We could provide (and document) a very simple registry base class with a normalized API that didn't have any of this conceptual baggage; it would be extremely popular, I think. Likewise, it should be possible to use a different registry implementation to service the ZCA global API. This is possible right now via getSiteManager.sethook, of course. You factored various related things together - perhaps it would make sense to do this refactoring within zope.component? I'm +1 on making zope.event part of zope.component and deprecating zope.event. Speculating, would it instead make sense to move zope.registry functionality into zope.interface? The only additional dependency is zope.event. At first glance the answer would be no as it really introduces various component architecture concepts... It might make sense to me to put a very simple component registry in zope.interface: it already has the concept of adapter baked in. Yeah, I think this makes more sense. So, we have a number of projects: * interface API - the stuff around calling interface I sketched out elsewhere. I think this is relatively low-hanging fruit. On the other hand it breaks backwards compatibility. I wouldn't want this project to depend on the other improvements, and I don't think it has to, so I'd like to see this as zope.component 4.0. * improving and move code that's general enough from zope.component into zope.interface. What this would look like I'm not quite sure about yet, as zope.registry at first glance contains a lot of knowledge about utilities and such still. There are backwards compatibility issues surrounding persistence but hopefully less around the APIs themselves. * an improved registration API for zope.component. This would affect a lot of code that does registration. Documentation projects should go along with all of those. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Chris McDonough wrote: Martijn Faassen wrote: Hey, Christian Theune wrote: [snip] Another option would be to provide a backwards-compatibility mode of our code which can be switched on and off. Your notion of bringing the component lookup mechanics closer to being a language feature is very intriguing and I like it a lot. However, if we do so, I'd like us to not having to resort to second-best spelling/implementation due to backwards compatbility. I'd like to work pretty hard on doing the implementation we want because it's a good implementation and then make backwards compatibility work. (I know, I'm a dreamer ...) I'd be in favor of an API based off calling the interface directly for everything *if* we can come up with a backwards compatibility story somehow. Just as a data point, I forgot to hook adapter_hook in BFG (and I still haven't), which means that the IFoo() sugar doesn't work. Nobody noticed, even though lots of folks who use BFG also use the ZCA global API. I'm not implying that this means it's not useful or convenient for old hands. But the old hands don't really need it. Interesting. If you mostly do multi-adaptation (and utility lookups) you won't notice it as we know multi adaptation cannot be done with the adapter hook. Was this the case? I really have trouble remembering the lookup APIs in zope.component myself. People in my experience actually *try* to do multi adaptation using the IFoo adapter hook and then get confused because it fails. If the primary goal is to increase adoption, I think further abstraction of stuff behind nicer calling conventions won't help improve matters: people really need to understand the A-through-Y concepts before they can jump to Z; promoting Z before better explaining A-through-Y first will only add more confusion. We currently do a pretty poor job of explaining A-Y, at least in all the documentation I've read. I think this implies that we need to break down the concepts into more consumable layers and document each of them before we add more abstraction. (as I said elsewhere): My primary goal here is to improve life for those already using the APIs. But I agree we should definitely improve documentation for it too as we go along, and I will help with that. [I think there are decent explanations of at least adaptation floating around, but not along with zope.component, and important bits such as utilities are probably underdocumented] Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Fri Nov 27 12:00:00 2009 UTC to Sat Nov 28 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Nov 27 20:38:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013095.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Nov 27 20:40:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013096.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Fri Nov 27 20:42:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013097.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Nov 27 20:44:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013098.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Fri Nov 27 20:46:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013099.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Nov 27 20:48:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013100.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen faas...@startifact.com wrote: Adam GROSZER wrote: I had a feeling that adapter lookup can be alone slowish with lots of registrations. We had a large project that was cut in half and the z3c.form UI, which is rather heavily adaptation based got a boost after that. What is a large project in your case? Just as an example here's the size of the global registry in a typical Plone project: getGlobalSiteManager() BaseGlobalComponents base len(getGlobalSiteManager()._utility_registrations) 1091 len(getGlobalSiteManager()._adapter_registrations) 1283 len(getGlobalSiteManager()._handler_registrations) 139 len(getGlobalSiteManager()._subscription_registrations) 3 Interesting. It'd be interesting to do some experiments with this. Could you perhaps look into writing some kind of stress-test script? I haven't done any real performance measurements but the various zope.interface/component API's are among the top of every profile run I do in Plone. To me it looks like checking if an interface is provided by a context is non-trivial and the main bottleneck in our case. The classes underlying our typical contexts are pretty fat classes with a long inheritance chain contributing dozens of interfaces. The actual registry lookups seem to be rather fast, they should be essentially dict lookups, which perform well with a dict size of just about 1000. On the other hand I noticed that z3c.form and it's use of the ZCA is indeed much slower than stitching forms together via ZPT macros as done for example by Archetypes. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: Well, I don't think the difference between adapters and utilities is important, but I can understand why some people find calling the interface odd: it is when you think about it objectively. I have to agree with this. IFoo(myobject) is not intuitive. I know it used a lot because it's convenient shorthand but I've never read anywhere that interface classes are, in fact, callables. We certainly don't normally treat them as such. One of the things that I have grown to appreciate with the ZCA is the advantage of spelling out the relationship between objects and I'll happily take a little verbosity over magic. The discussion does highlight a key source of confusion about Zope interfaces: they are, at the same time, an object specification and a kind of name tag or token that objects can provide upon request. While I know that the second function is derived from the first it is conceptually different. My preference, for the sake of clarity: adapted = an_easy_way_to_the_registry.adapt(*objects_to_be_adapted, **identifiers) That adapters are all callable now seems to be an accepted convention, presumably from convenience. But my understanding of adapters does not imply this. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Charlie Clark wrote:
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers ch...@simplistix.co.uk:
Well, I don't think the difference between adapters and utilities is
important, but I can understand why some people find calling the
interface odd: it is when you think about it objectively.
I have to agree with this. IFoo(myobject) is not intuitive. I know it used
a lot because it's convenient shorthand but I've never read anywhere that
interface classes are, in fact, callables. We certainly don't normally
treat them as such.
It's quite intuitive to me..
Compare it with plain python:
int(something)
or:
str(something)
len(something)
You say give me something that's an int for the argument, or give me
something that's a string for the argument. You don't care how it
accomplishes it, as long as it gives the right value back.
It's even like adapters in the following way:
int(1)
Gives back the object itself, as it already is an int.
int('1')
int(1.5)
Int is also registered for strings and floats, but essential different
styles of adaptation happen there.
Calling an interface is really very similar to this.
The main difference is that we don't use the concrete implementation's
factory but that we use the interface that specifies the abstract
behavior. That is a difference, but doesn't seem to be a huge step in my
mind.
One of the things that I have grown to appreciate with the ZCA is the
advantage of spelling out the relationship between objects and I'll
happily take a little verbosity over magic.
It's not verbosity versus magic. It's a better API versus a worse API.
The discussion does highlight a key source of confusion about Zope
interfaces: they are, at the same time, an object specification and a kind
of name tag or token that objects can provide upon request. While I know
that the second function is derived from the first it is conceptually
different.
My preference, for the sake of clarity:
adapted = an_easy_way_to_the_registry.adapt(*objects_to_be_adapted,
**identifiers)
I'm not sure how this is supposed to work; what is identifiers?
That adapters are all callable now seems to be an accepted convention,
presumably from convenience. But my understanding of adapters does not
imply this.
I hope to have shown to you above that my understanding of adapters does.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] make zope.component.registry.Components inherit from dict?
Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough chr...@plope.com: We've been handling some constructive criticisms from repoze.bfg developers with respect to verbosity resulting from use of unnamed utility registrations in a component architecture registry. These criticisms, and our ameliorations are detailed here: http://docs.repoze.org/bfg/1.1/designdefense.html#bfg-uses-the-zope-component-architecture-zca An interesting document and discussion. Having struggled initially and in some ways still struggling to grasp the ZCA I can understand the temptation to try and hide it from developers because they don't need it to get their job done. But my own take on the ZCA is that the component registry is nothing wildly complicated just significantly different from what many people are used to. But once you know it's there and that it just looks after components it's just like having a DBMS manage your data for you: throw stuff into it and it will manage your stuff for you. I recently gave a presentation on the ZCA to non-Zopers and the concepts weren't too difficult for the audience (I find it helps to jazz up the metaphors). Conceptually the biggest problems are probably the multi-key (nature of component, interface, name) nature of the registry and the function of an interface as the token or smartcard required to get the desired component. In the example from repoze.bfg.interfaces import ISettings from zope.component import getUtility settings = getUtility(ISettings) the biggest leap of faith is getUtility which makes a behind the scenes call to which registry is present. I can imagine a clearer implementation that would do the same but be explicitly dependent upon a particular registration. registry.get((utility, ISettings, u'')) This would, of course, be available as a dictionary call, although I'm not sure I'd see great advantage in that. All assuming, of course, the implemntation didn't clash with a localSiteManager but I think from other posts that it does. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Am 28.11.2009, 16:06 Uhr, schrieb Martijn Faassen faas...@startifact.com:
I have to agree with this. IFoo(myobject) is not intuitive. I know it
used
a lot because it's convenient shorthand but I've never read anywhere
that
interface classes are, in fact, callables. We certainly don't normally
treat them as such.
Hi Maartijn,
It's quite intuitive to me..
Compare it with plain python:
int(something)
or:
str(something)
len(something)
You say give me something that's an int for the argument, or give me
something that's a string for the argument. You don't care how it
accomplishes it, as long as it gives the right value back.
It's even like adapters in the following way:
int(1)
Gives back the object itself, as it already is an int.
int('1')
int(1.5)
Int is also registered for strings and floats, but essential different
styles of adaptation happen there.
So adapters are reduced to type conversion?
Calling an interface is really very similar to this.
The main difference is that we don't use the concrete implementation's
factory but that we use the interface that specifies the abstract
behavior. That is a difference, but doesn't seem to be a huge step in my
mind.
Thanks for the comparison but it is semantically so different and
interfaces can be used for things other than adapters that I disagree. The
most common example I know of the syntax is with INameChooser() which
brings us back to the differences (real or imaginary) between utilities
and adapters.
One of the things that I have grown to appreciate with the ZCA is the
advantage of spelling out the relationship between objects and I'll
happily take a little verbosity over magic.
It's not verbosity versus magic. It's a better API versus a worse API.
The discussion does highlight a key source of confusion about Zope
interfaces: they are, at the same time, an object specification and a
kind
of name tag or token that objects can provide upon request. While I know
that the second function is derived from the first it is conceptually
different.
My preference, for the sake of clarity:
adapted = an_easy_way_to_the_registry.adapt(*objects_to_be_adapted,
**identifiers)
I'm not sure how this is supposed to work; what is identifiers?
That makes two of us! ;-) identifiers would be the key components -
Interface/Tag (which is how I think of them in this context) and possibly
name.
That adapters are all callable now seems to be an accepted convention,
presumably from convenience. But my understanding of adapters does not
imply this.
I hope to have shown to you above that my understanding of adapters does.
It's quite likely that I'm wrong in this but I see great potential using
adapters for delegation rather than straight conversion. I have very much
come to appreciate the power of this delegation in, say, BrowserViews;
even if it did take me several months to understand the multiadapter
pattern!
Because I do, repeatedly, make simple mistakes with the adapter, utility
(wrong name, wrong signature) stuff I very much appreciate attempts to
simplify and clarify the API. But I will greet them the same poor grasp of
the underlying concepts than I did the originals!
Charlie
--
Charlie Clark
Managing Director
Clark Consulting Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Sat, Nov 28, 2009 at 16:39, Charlie Clark charlie.cl...@clark-consulting.eu wrote: So adapters are reduced to type conversion? That's what adapters are. They aren't reduced to it, it's what they do. They adapt one object with one interface to have another interface. That can indeed be seen as a type conversion. Thanks for the comparison but it is semantically so different and interfaces can be used for things other than adapters that I disagree. Yes but adapters can only be used as adapters, and the topic was the syntax for adapting an object. The most common example I know of the syntax is with INameChooser() which brings us back to the differences (real or imaginary) between utilities and adapters. I agree that calling an interface like that is a strange thing to do. I don't know what that would do, even. I have however never ever seen that done. It's quite likely that I'm wrong in this but I see great potential using adapters for delegation rather than straight conversion. But the delegation is adaptation. There is no difference. I have very much come to appreciate the power of this delegation in, say, BrowserViews; even if it did take me several months to understand the multiadapter pattern! I hear this a lot, so this is apparently something that is common to take a while to grasp. Any ideas of what to make multi-adapters more understandable would probably be a good thing. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Lennart Regebro wrote: I have very much come to appreciate the power of this delegation in, say, BrowserViews; even if it did take me several months to understand the multiadapter pattern! I hear this a lot, so this is apparently something that is common to take a while to grasp. Any ideas of what to make multi-adapters more understandable would probably be a good thing. The typical misunderstanding starts like this, I think: - The developer performs some set of adapter registrations in setup. - The developer wants to do an adapter lookup at runtime. He often doesn't know which adapter he'll get back when he does a lookup, especially when he registers a number of adapter factories for less specific types than he wants to provide as requires lookup parameters. Multiadapters add to the mystery because the relative order of the requires arguments has an impact on which adapter is returned when there's more than one candidate adapter factory. This confusion comes about mostly because the algorithm that the registry uses to choose an adapter factory (even for single-adaptation) is not documented or specified in a consumable format anywhere. Personally, even I don't really know how it works. It would be useful if someone who did know how it worked created an analogue of this: http://docs.repoze.org/component/basic.html#component-lookup-order-when-requires-arguments-are-specified - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Martijn Faassen wrote: Chris McDonough wrote: Martijn Faassen wrote: [snip] So now that we've had some discussion and to exit the bikeshed phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible. I suggest we think to ourselves who the primary beneficiary of this goal is. I don't really disagree with anything you say here in absolute terms, but if the goal is increased adoption by new users, I think there are (relatively) more fundamental things that could be done to help. For this measure I'm not interested in increased adoption by new users. I just want to be able to have a more convenient way to express these things. So, my goal is to make life easier for myself (and hopefully others). Fair enough. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro rege...@gmail.com: That's what adapters are. They aren't reduced to it, it's what they do. They adapt one object with one interface to have another interface. That can indeed be seen as a type conversion. I agree that that is probably the most common use for them. Thanks for the comparison but it is semantically so different and interfaces can be used for things other than adapters that I disagree. Yes but adapters can only be used as adapters, and the topic was the syntax for adapting an object. My point is you can't necessarily tell much from the interface name. The most common example I know of the syntax is with INameChooser() which brings us back to the differences (real or imaginary) between utilities and adapters. I agree that calling an interface like that is a strange thing to do. I don't know what that would do, even. I have however never ever seen that done. It's utility for avoid name conflicts when adding a new object to a container: from zope.container.interfaces import INameChooser name = INameChooser(container).chooseName(obj.getId(), obj) It's quite likely that I'm wrong in this but I see great potential using adapters for delegation rather than straight conversion. But the delegation is adaptation. There is no difference. For me, conceptually, there is quite a difference. An adapter is closely coupled to the object it is adapting. The common example is the headphone jack - electric impulses in and out. Delegation, at least the way I think of it, places the emphasis on separating the functionality, ie. decoupling, of the adapter from the object being adapted, even though technically it's exactly the same. I think of adapters as the gadgets that James Bond gets given by Q - it helps me get away from thinking about implementation. I have very much come to appreciate the power of this delegation in, say, BrowserViews; even if it did take me several months to understand the multiadapter pattern! I hear this a lot, so this is apparently something that is common to take a while to grasp. Any ideas of what to make multi-adapters more understandable would probably be a good thing. hm, good question. With BrowserViews I think the problem is possibly with the whole idea of the REQUEST object which it's easy to oversee and just treat like a dictionary or storage. I normally concentrate on emphasising that the view has been delegated presentational responsibility by the content object in a particular context (maybe it is easier to understand adapting the content object and the request for a piece of HTML or PDF, etc.). Would it be too far fetched to imagine an engine adapting a car and petrol to provide motion? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Martijn Faassen wrote: I'd be in favor of an API based off calling the interface directly for everything *if* we can come up with a backwards compatibility story somehow. Just as a data point, I forgot to hook adapter_hook in BFG (and I still haven't), which means that the IFoo() sugar doesn't work. Nobody noticed, even though lots of folks who use BFG also use the ZCA global API. I'm not implying that this means it's not useful or convenient for old hands. But the old hands don't really need it. Interesting. If you mostly do multi-adaptation (and utility lookups) you won't notice it as we know multi adaptation cannot be done with the adapter hook. Was this the case? It's hard to know. No application written using BFG can use the IFoo() pattern at all, and no one complained. The only generalization I can take away from that is that anyone who has written a BFG app and also used the ZCA APIs did not care about the IFoo() pattern. That's maybe not a really useful generalization, because many BFG apps don't use the ZCA APIs at all. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] make zope.component.registry.Components inherit from dict?
Charlie Clark wrote: Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough chr...@plope.com: We've been handling some constructive criticisms from repoze.bfg developers with respect to verbosity resulting from use of unnamed utility registrations in a component architecture registry. These criticisms, and our ameliorations are detailed here: http://docs.repoze.org/bfg/1.1/designdefense.html#bfg-uses-the-zope-component-architecture-zca An interesting document and discussion. Having struggled initially and in some ways still struggling to grasp the ZCA I can understand the temptation to try and hide it from developers because they don't need it to get their job done. But my own take on the ZCA is that the component registry is nothing wildly complicated just significantly different from what many people are used to. But once you know it's there and that it just looks after components it's just like having a DBMS manage your data for you: throw stuff into it and it will manage your stuff for you. I recently gave a presentation on the ZCA to non-Zopers and the concepts weren't too difficult for the audience (I find it helps to jazz up the metaphors). Conceptually the biggest problems are probably the multi-key (nature of component, interface, name) nature of the registry and the function of an interface as the token or smartcard required to get the desired component. In the example from repoze.bfg.interfaces import ISettings from zope.component import getUtility settings = getUtility(ISettings) the biggest leap of faith is getUtility which makes a behind the scenes call to which registry is present. Right. I can imagine a clearer implementation that would do the same but be explicitly dependent upon a particular registration. registry.get((utility, ISettings, u'')) In a Zope app, you can use this pattern today to make that true: from zope.component import getSiteManager registry = getSiteManager() settings = registry.getUtility(ISettings) In a BFG app the same thing would be best done as: from repoze.bfg.threadlocal import get_current_registry registry = get_current_registry() settings = registry.getUtility(ISettings) (This is a little clearer maybe than using the site manager terminology.) If a request object was available in that BFG app, it would be better done as: registry = request.registry settings = registry.getUtility(ISettings) I agree that the extra verbosity of explicitly obtaining the registry and calling methods on it improves readability. It's the API of the registry object I'd like to make better. I'm not as concerned about the global ZCA API. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Sat, Nov 28, 2009 at 17:35, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro rege...@gmail.com: That's what adapters are. They aren't reduced to it, it's what they do. They adapt one object with one interface to have another interface. That can indeed be seen as a type conversion. I agree that that is probably the most common use for them. No, that's what they are. An adapter is something that adapts one interface to another. That's the definition of the adapter pattern. It's not the most common usecase, thats THE usecase. If it doesn't do that, it's not an adapter. My point is you can't necessarily tell much from the interface name. Of course. I agree that calling an interface like that is a strange thing to do. I don't know what that would do, even. I have however never ever seen that done. It's utility for avoid name conflicts when adding a new object to a container: from zope.container.interfaces import INameChooser name = INameChooser(container).chooseName(obj.getId(), obj) Ah, OK. You skipped the container parameter. That's just an adapter. But the delegation is adaptation. There is no difference. For me, conceptually, there is quite a difference. An adapter is closely coupled to the object it is adapting. Absolutely. The common example is the headphone jack - electric impulses in and out. Delegation, at least the way I think of it, places the emphasis on separating the functionality, ie. decoupling, of the adapter from the object being adapted, even though technically it's exactly the same. Well, that's just a matter of creating the Interface with a specific goal in mind. You separate two types of adapters in your inner conceptualisation: Case 1. I have an American Power port, but I need to put it into a european one, so I get an adapter. Case 2. I'm going to make a laptop power supply. I therefore design it so that I can connect various adapters into the power supply, MacBook adapter style. In the first case I have two interfaces designed by others, and adapt on to the other. In the second case, I design an interface specifically so it will be easy to make adapters for it to the different uses I envision. But those cases are still just adapters. It's different situtions to be in as a programmer, but technically they are exactly the same. It's just adapters. I think of adapters as the gadgets that James Bond gets given by Q - it helps me get away from thinking about implementation. I don't see how that works. hm, good question. With BrowserViews I think the problem is possibly with the whole idea of the REQUEST object which it's easy to oversee and just treat like a dictionary or storage. I normally concentrate on emphasising that the view has been delegated presentational responsibility by the content object in a particular context (maybe it is easier to understand adapting the content object and the request for a piece of HTML or PDF, etc.). Would it be too far fetched to imagine an engine adapting a car and petrol to provide motion? Works for me. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Just re-inforcing this I almost never do IFoo. adaption as I am almost always using multiadapters and utilities so I completely forget about the IFoo adaption capability. Which means I always just write getAdapter as well as it seems more consistent to from an api consumption point of view. T Interesting. If you mostly do multi-adaptation (and utility lookups) you won't notice it as we know multi adaptation cannot be done with the adapter hook. Was this the case? I really have trouble remembering the lookup APIs in zope.component myself. People in my experience actually *try* to do multi adaptation using the IFoo adapter hook and then get confused because it fails. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Get raw data (byte array) from flash in Zope
Hi,
The solution is very simple :)
Instead of sending the byte array like in the example, just encode it
as a string and send it in a variable using POST:
- base64 - this doesn;t works all the time... i don't know why
- bin to hex - works all the time
The server side code is like this:
img = REQUEST.form.get('picture', None)
if img is not None and img != '':
img = binascii.unhexlify(img)
img = PIL.Image.open(StringIO(img))
img.save(join(..., 'picture.jpg'))
We made tests with a lot of images, even with images of 10MB size. It works...
Dragos
On Wed, Nov 25, 2009 at 8:30 PM, Dragos Chirila objectval...@gmail.com wrote:
The data is actually received by Zope, but its broken into pieces.
Please find a sample of the REQUEST.form here
http://media.fourhooks.ro/request_form.jpg
Any hints on how to put the image back together?
On Wed, Nov 25, 2009 at 4:58 PM, Dragos Chirila objectval...@gmail.com
wrote:
Doesn't work: AttributeError: BODYFILE
On Wed, Nov 25, 2009 at 1:59 PM, Stefan H. Holek ste...@epy.co.at wrote:
Try REQUEST.BODYFILE
On 25.11.2009, at 12:30, Dragos Chirila wrote:
The question is: how can I get this data on the server side in Zope?
Becasue:
- REQUEST.form is empty
- HTTP_RAW_POST_DATA is missing
- there is no other key or value in the REQUEST to indicate the value
I am looking for
--
Stefan H. Holek
ste...@epy.co.at
--
Dragos Chirila
objectval...@gmail.com
(+4) 0722 395375
--
Dragos Chirila
objectval...@gmail.com
(+4) 0722 395375
--
Dragos Chirila
objectval...@gmail.com
(+4) 0722 395375
___
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )
