Re: [Zope-dev] zope.globalrequest?
Roger Ineichen wrote: I see your point. I'm not saying that this is bad in general. Probably when used in moderation is the right concept for this package ;-) and it wasn't written with anything else in mind -- merely for the odd case when you need a request object, but none has been passed around. imho, it makes more sense to use a defined API in those cases instead of relying on knowledge about the current implementation. i mean, sometimes it's not possible to adjust the design and change all of the involved code (at least not timely), in which case people may resolve to simply fetch the request from anywhere they know it's accessible. a common API does help here, especially when it comes to changing things. but like i said, that's not supposed to mean `zope.globalrequest` was to promote a new pattern for zope development. cheers, 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.5.1 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] zope.globalrequest?
On Mon, Jan 19, 2009 at 10:07 AM, Martijn Faassen faas...@startifact.com wrote: I guess I might've been able to use the interaction directly in Zope 3's case and I shall study that. I suspect you already know the mechanics of getting the request from the interaction, but for the others, here's a code snippet that does it: http://wiki.zope.org/zope3/FAQProgramming#how-do-i-get-irequest-object-in-event-handler -- 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?
Hi Martijn Betreff: Re: [Zope-dev] zope.globalrequest? Hi there, Roger Ineichen wrote: [snip] Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I don't think that's always true. Let me give you an example. I wrote a library called hurry.resource. This library is framework neutral. You can define a javascript or css resource and express that you need it to be included in the page in a certain code path: yui.datatable.need() I also have a library called hurry.zoperesource. This library provides integration of hurry.resource with Zope 3. When need() is called in a Zope 3 context, I need the request object as I chose the request object as the place to store the list of resources that are needed. So I need to get the request without having it. You could argue my library isn't designed right, and that instead I should require people to pass 'request' to the .need() method. But since hurry.resource is framework-neutral, what request should that be? And in a system like Pylons it makes no sense to have to pass in the request, as it's available globally everywhere. It only seems to put an implementation detail into the API. Besides the framework neutralness argument, which you can argue makes no sense, I think it's simply a nicer API to say '.need()' instead of having to pass the request. That's a weaker argument, however. That said, zc.resourcelibrary does the same strategy, as that's where I took it from. Anyway, I do believe there are cases of APIs that need the request internally but want to abstract it away as an implementation detail. I guess I might've been able to use the interaction directly in Zope 3's case and I shall study that. There are of course drawbacks (as mentioned) with testing and such when taking this approach. But I think one can make a reasonable case for such an API nonetheless, when used in moderation. I see your point. I'm not saying that this is bad in general. Probably when used in moderation is the right concept for this package ;-) Regards Roger Ineichen 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 ) ___ 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 there, Oh joy, a naming discussion. :) A namespace isn't a framework. Be careful we don't start pretending that the zope.* namespace is a framework. If you start judging which packages belong in the zope.* namespace and which are not, what standards are really being used? The only standard I've seen in this thread was something about the elder Zope gods writing into stone what shall go into zope.* and what shall not. I don't think that's a sensible position for a framework that's supposed to be evolving. Or isn't it? The Zope 3 framework isn't all zope.* packages. It's a selection made carefully by developers of the framework that can be installed as a whole. Okay, scratch that, as Zope 3 is a bad example of this for some reason. I'm not sure that's a good thing; a framework without people who decide what goes into it? How does one install Zope 3? It works for Grok though: The Grok framework is a bunch of zope.*, grokcore.*, z3c.*, zc.* and packages, and other packages to boot, integrated together that can be installed as a whole. The Grok development team determines what's part of a core Grok installation. It also works for Zope 2. 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: On 17.01.2009 8:39 Uhr, Dieter Maurer wrote: [snip] 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 +1 too. For Zope 2 and for Zope 3. In some cases it's really hard to get to the request otherwise. Take a look at zc.resourcelibrary for a Zope 3 library that could use zope.globalrequest. Right now it doesn't use an abstraction but just cheats by knowing the implementation. Or hurry.zoperesource, which uses the same pattern. 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?
Hi there, Roger Ineichen wrote: [snip] Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I don't think that's always true. Let me give you an example. I wrote a library called hurry.resource. This library is framework neutral. You can define a javascript or css resource and express that you need it to be included in the page in a certain code path: yui.datatable.need() I also have a library called hurry.zoperesource. This library provides integration of hurry.resource with Zope 3. When need() is called in a Zope 3 context, I need the request object as I chose the request object as the place to store the list of resources that are needed. So I need to get the request without having it. You could argue my library isn't designed right, and that instead I should require people to pass 'request' to the .need() method. But since hurry.resource is framework-neutral, what request should that be? And in a system like Pylons it makes no sense to have to pass in the request, as it's available globally everywhere. It only seems to put an implementation detail into the API. Besides the framework neutralness argument, which you can argue makes no sense, I think it's simply a nicer API to say '.need()' instead of having to pass the request. That's a weaker argument, however. That said, zc.resourcelibrary does the same strategy, as that's where I took it from. Anyway, I do believe there are cases of APIs that need the request internally but want to abstract it away as an implementation detail. I guess I might've been able to use the interaction directly in Zope 3's case and I shall study that. There are of course drawbacks (as mentioned) with testing and such when taking this approach. But I think one can make a reasonable case for such an API nonetheless, when used in moderation. 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?
On Sun, 18 Jan 2009 20:29:40 +0100 Dieter Maurer die...@handshake.de wrote: Tres Seaver wrote at 2009-1-18 11:38 -0500: ... I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, This is not the case for localsitemanager delivered local utilities and we therefore have had several problems. while Z3 apps use the separation of concerns pattern I just outlined. Nobody forces you to go this route. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. You could use the same arguments with respect to the global site ;-) But few people in Zope 3 land separate site dependent and site independent code despite some cases where the global site does make problems. Using the 'reversal of dependency' (not sure whether this is the accurate English term) you always end up with a few general concepts that act as mediators. Sites are badly named 'component registries' and are part of the central zope.component module which acts as the general plug-in point, thus the dependency. The ZCA is intended to be depended on and activating registries is a part of that. The comparison of a component registry versus a request does not hold IMHO. Depending on a request is generally not good and most people in this thread acknowledged this, pointing out that they still want the flexibility. I'd be happy with a reasonable documentation pointing out that accessing a request from anywhere is definitely not intended to be turned into an *everywhere* but needs careful though. For me, if my apps domain logic can't be used in `bin/zopectl debug` (or run) without faking a request, they're broken. 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 ___ 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 Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. 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 Mon, 19 Jan 2009 09:24:09 -0800 Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. Thanks. Now, that you mention it ... 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 ___ 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 Stephan Richter wrote: On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. I think maybe inversion is the term desired.. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdNbR+gerLs4ltQ4RAl5CAKCH7xJXGKqHVEUG9WMcsWyHwtnlXwCgz9Pd rQO99ttrtgb/WulLn375YaA= =issy -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] zope.globalrequest?
On Mon, Jan 19, 2009 at 09:24:09AM -0800, Stephan Richter wrote: On Monday 19 January 2009, Christian Theune wrote: Using the 'reversal of dependency' (not sure whether this is the accurate English term) I think it is called dependency injection. There's the Dependency Inversion Principle (DIP), which says that high-level modules shouldn't depend on low-level modules; instead they both should depend on an abstraction. - http://en.wikipedia.org/wiki/Dependency_inversion_principle And then there's the Dependency Injection Pattern, which is, I suppose, an implementation of the DIP, where classes don't instantiate their dependencies directly, and instead expect the client to supply them. - http://en.wikipedia.org/wiki/Dependency_injection Then there's also Inversion of Control, which is a principle advocating framework-ish behaviour (you supply callbacks, we call them when we want) over library-ish behaviour (we supply utilities, you call them when you want), and could be called an abstract principle behind both DIP and DI -- http://en.wikipedia.org/wiki/Inversion_of_control Oh dear, now I'm confused. ;-) Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital 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] zope.globalrequest?
Roger Ineichen wrote: I don't say that this is bad in general. I just say that if you build an application based on zope.globalrequest, this is a totaly different base concept how you will develop applications like we do now. And you have to pay the price with a complex test setup. it's merely one more package and its zcml (setting up two event subscribers). considering the complexity of the stack as we know it i don't think it really adds that much, no? 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] zope.globalrequest?
Hi Andi Betreff: Re: [Zope-dev] zope.globalrequest? Roger Ineichen wrote: I don't say that this is bad in general. I just say that if you build an application based on zope.globalrequest, this is a totaly different base concept how you will develop applications like we do now. And you have to pay the price with a complex test setup. it's merely one more package and its zcml (setting up two event subscribers). considering the complexity of the stack as we know it i don't think it really adds that much, no? I think it's more then that It changes the way you will think about MVC and the way you develop and take care on separate your model, view controller components. It's like aquisition in Zope 2, you don't have to take care where your attributes coming from, they're just there. Doesn't matter if this is good or bad, it's just a very different concept. Defently a bad thing is, if to many developer start using zope.globalrequest in their 3rd party packages. We can't reuse this 3rd party packages whithout using a global request variable. In my point of view it's a fundamental change on what an application is built on. Probably the good thing is, it's easy to provide such a global request as long as you use a webserver (publisher). just a sample; In my point of view an application like a wiki or forum etc. should get developed as a python application without to require a global request because it's just a (MVC) model part. There should never be a request involved. If such a wiki needs a last modified user argument. This should not get set by a global request lookup. Or at least not the model should use such a global request by itself. If you need to set such a last user modified argument the view/controller should be responsible for doing so. I'm pretty sure if we have a global request available we will see very quick that developer start to use the global request in the model part. Note, mixin model, view and controller responisibilities into one component/object make it allmost impossible to replace or reuse parts of it. Regards Roger Ineichen 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 ) ___ 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?
Roger Ineichen wrote: just a sample; In my point of view an application like a wiki or forum etc. should get developed as a python application without to require a global request because it's just a (MVC) model part. There should never be a request involved. If such a wiki needs a last modified user argument. This should not get set by a global request lookup. Or at least not the model should use such a global request by itself. If you need to set such a last user modified argument the view/controller should be responsible for doing so. I'm pretty sure if we have a global request available we will see very quick that developer start to use the global request in the model part. Note, mixin model, view and controller responisibilities into one component/object make it allmost impossible to replace or reuse parts of it. The most convincing reason for me to persevere with the current pattern of views is that it offers the possibility of adaption on the request. This is something that repoze.bfg is exploring and I think could be helpful, for instance registering separate views on POSTRequest from GETRequest. I don't see anything wrong in allowing a utility access to the request without explicitly including it in its method signature. If they choose to use it from a model, it's their foot and they are free to shoot it if they wish. Laurence ___ 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?
Regards Roger Ineichen _ END OF MESSAGE -Ursprüngliche Nachricht- Von: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] Im Auftrag von Laurence Rowe Gesendet: Sonntag, 18. Januar 2009 16:43 An: zope-dev@zope.org Betreff: Re: [Zope-dev] zope.globalrequest? Roger Ineichen wrote: just a sample; In my point of view an application like a wiki or forum etc. should get developed as a python application without to require a global request because it's just a (MVC) model part. There should never be a request involved. If such a wiki needs a last modified user argument. This should not get set by a global request lookup. Or at least not the model should use such a global request by itself. If you need to set such a last user modified argument the view/controller should be responsible for doing so. I'm pretty sure if we have a global request available we will see very quick that developer start to use the global request in the model part. Note, mixin model, view and controller responisibilities into one component/object make it allmost impossible to replace or reuse parts of it. The most convincing reason for me to persevere with the current pattern of views is that it offers the possibility of adaption on the request. This is something that repoze.bfg is exploring and I think could be helpful, for instance registering separate views on POSTRequest from GETRequest. I don't see anything wrong in allowing a utility access to the request without explicitly including it in its method signature. If they choose to use it from a model, it's their foot and they are free to shoot it if they wish. Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. I fully agree with Christian if he says this is an anti pattern. Not ure but probably Reinventing the square wheel is the anti pattern was thinking about. http://en.wikipedia.org/wiki/Reinventing_the_square_wheel Regards Roger Ineichen Laurence ___ 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 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?
Roger Ineichen wrote: The most convincing reason for me to persevere with the current pattern of views is that it offers the possibility of adaption on the request. This is something that repoze.bfg is exploring and I think could be helpful, for instance registering separate views on POSTRequest from GETRequest. I don't see anything wrong in allowing a utility access to the request without explicitly including it in its method signature. If they choose to use it from a model, it's their foot and they are free to shoot it if they wish. Why should someone use a global request if he has a request available? This package does nothing else then offer a request if non is available. And if you need a request if non is available there is something wrong with the application design. Or better let's say it's another pattern then we use in zope 3 right now. Yes, it is a different pattern to the one used by pure zope 3 right now, but it is a pattern that would have allowed the transition of CMF tools to utilities. The perfect is the enemy of the good. - Voltaire Laurence ___ 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 Laurence Rowe wrote: Roger Ineichen wrote: just a sample; In my point of view an application like a wiki or forum etc. should get developed as a python application without to require a global request because it's just a (MVC) model part. There should never be a request involved. If such a wiki needs a last modified user argument. This should not get set by a global request lookup. Or at least not the model should use such a global request by itself. If you need to set such a last user modified argument the view/controller should be responsible for doing so. I'm pretty sure if we have a global request available we will see very quick that developer start to use the global request in the model part. Note, mixin model, view and controller responisibilities into one component/object make it allmost impossible to replace or reuse parts of it. The most convincing reason for me to persevere with the current pattern of views is that it offers the possibility of adaption on the request. This is something that repoze.bfg is exploring and I think could be helpful, for instance registering separate views on POSTRequest from GETRequest. BFG has always looked up views by adaptation of context and request, using the ZCA: there isn't anything we are exploring about that, although Chris moved the method-name-based factories from an external package into the core recently, making it easier to use the RESTy request types. I don't see anything wrong in allowing a utility access to the request without explicitly including it in its method signature. If they choose to use it from a model, it's their foot and they are free to shoot it if they wish. If a utliity *must* have access to the request, then it should either be a view (and get it for free) or get it passed to it from a view as an argument. That is how the ZCA is suppoed to be used, separating the concerns between request-dependant and request-independent code. I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, while Z3 apps use the separation of concerns pattern I just outlined. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJc1ry+gerLs4ltQ4RAqtyAKCSkm/O+3pNv/d7xIwXZjWl0N+LjwCcDKqh pIIBN2SqbQGMJcGrlFa87+g= =Ak9N -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] zope.globalrequest?
Previously Tres Seaver wrote: I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, while Z3 apps use the separation of concerns pattern I just outlined. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. Z2 apps are increasingly not able to acquire the rest due to the use of utilities, and utilities trying to use Zope2 code that assumes the request can be acquired. This is very noticable in CMF with the GenericSetup setup tool. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, while Z3 apps use the separation of concerns pattern I just outlined. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. Your point of view is in general correct. However there are situations were you don't have access direct access to a request and when changing/fixing the underlaying framework(s) isn't a option. I had this issue frequently with the 'validation' module of Archetypes. Using zope.globalrequest as a workaround is in this case a much better than solution than hacking the framework. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAklzXX4ACgkQCJIWIbr9KYzsKwCgmCKIzx0eSTPRPUA3nUhldRBG b7gAn2DICuuzvAZ0Z7Bm1NnR10BzpDkU =w+V4 -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?
Roger Ineichen wrote at 2009-1-18 13:04 +0100: ... 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. I'm fine with the zope.globalrequest package. But it's very important to understand that this is not a common way to do things. Nobody forces you to go this way. It also makes the request/interaction etc. a part of the test setup for test components. Probably it simplifies the implementation but brings in complexity in test testing an application. We test components nowadays that need a request. Not much will change when components assume they can get a request the zope.globarequest way. We create a request object and ensure that it is delivered the zope.globalrequest way. Note that Zope 3 handles the (global) site very similar to the way zope.globalrequest handles request. This, too, does not make tests impossible (or very difficult). to the way zope.globalrequest handles request. This, too, does not make tests impossible (or very difficult). I don't say that this is bad in general. I just say that if you build an application based on zope.globalrequest, this is a totaly different base concept how you will develop applications like we do now. And you have to pay the price with a complex test setup. I can live with this complexity :-) -- 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?
Tres Seaver wrote at 2009-1-18 11:38 -0500: ... I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, This is not the case for localsitemanager delivered local utilities and we therefore have had several problems. while Z3 apps use the separation of concerns pattern I just outlined. Nobody forces you to go this route. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. You could use the same arguments with respect to the global site ;-) But few people in Zope 3 land separate site dependent and site independent code despite some cases where the global site does make problems. -- 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?
Dieter Maurer wrote: 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. +1 However, there is a definite risk with it as well of encouraging poor separation of concerns. If code is dependent on a request it's not re-usable outside the web container. For views or web app controllers, that's certainly fine, but if you're writing something more generic, then it may be better to have the discipline to pass objects around that properly abstract your data, rather than assume you can access the request willy-nilly. This is a documentation issue, though. 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?
Hi, Am Samstag, den 17.01.2009, 11:36 + schrieb Martin Aspeli: Dieter Maurer wrote: 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. +1 +1 as well However, there is a definite risk with it as well of encouraging poor separation of concerns. If code is dependent on a request it's not re-usable outside the web container. For views or web app controllers, that's certainly fine, but if you're writing something more generic, then it may be better to have the discipline to pass objects around that properly abstract your data, rather than assume you can access the request willy-nilly. Isn't there always the risk that people design software the wrong way? This is a documentation issue, though. Martin 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?
Martin Aspeli wrote at 2009-1-17 11:36 +: Dieter Maurer wrote: 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. +1 However, there is a definite risk with it as well of encouraging poor separation of concerns. If code is dependent on a request it's not re-usable outside the web container. For views or web app controllers, that's certainly fine, but if you're writing something more generic, then it may be better to have the discipline to pass objects around that properly abstract your data, rather than assume you can access the request willy-nilly. We are in Python land -- and accustomed that using our freedoms occationally has a price :-) -- 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 )
[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 )
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 )
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] 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 )
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] 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] 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] 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] 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?
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?
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 Fri, Jan 16, 2009 at 3:06 PM, Hanno Schlichting hanno...@hannosch.eu 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?
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] 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?
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 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?
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?
-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?
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 )
