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?
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] SVN: Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py Hhm, pdb?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > Tres Seaver wrote: >> Hanno Schlichting wrote: >>> Log message for revision 94810: >>> Hhm, pdb?!? >>> Changed: >>> U Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >>> -=- >>> Modified: Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >>> === >>> --- Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >>> 2009-01-17 20:01:44 UTC (rev 94809) >>> +++ Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >>> 2009-01-17 20:41:54 UTC (rev 94810) >>> @@ -53,7 +53,6 @@ >>> for i in range( len( zipped ) ) >>> if zipped[i][0] != zipped[i][1] >>> ] >>> -import pdb; pdb.set_trace() >>> print 'Found:' >>> print fxml >> That breakpoint was inside an if block guarded by 'if debug:', which >> shouldn't be set by any "real" test. > > I can put it back if you want to. I'm just accustomed to a strict > "no-pdb"-policy in checked in code. Quite some repositories even enforce > it via a post-commit hook. You don't have to put it back, but you should likely delete the whole ;if debug:' block it was in while you are at it, as well as the 'debug' argument. All that stuff was there to dump useful output for the human just before hitting the breakbpoint. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJc2HM+gerLs4ltQ4RAp8PAKDW3SDlxgui67bP5dcQW+K85NrrEACfbrg0 yp1zQD9fASiR+fQCOo6TsT4= =6VqN -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?
-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?
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 It 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 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 Design"http://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] [Zope3-Users] Next Step to Bug Resolution???
Tim Cook schrieb: > class DataStructure(Persistence): >"""abstract class""" A typo? Do you use persistent.Persistent? > > class ItemStructure(DataStructure): > """abstract class""" From your description you should define interfaces for Item-/DataStructure, IItem/IDataStructure(Interface), that describe the interfaces the classes implement. The interaces these base classes implement are automatically implemented by their subclasses. > class ItemList(ItemStructure): > u""" > Logical list data structure, where each item has a value and can be > referred to by a name > and a positional index in the list. The list may be empty. > """ > > items = List( > value_type=Object(schema=IElement), > title=_(u"items"), > description=_(u"""Physical representation of the list."""), > required=False > ) # Did not look at the Object-Part as I don't use that, but afaik you # need to store objects that provide IElement (instances of classes that # implement IElement). class IItemList(Interface): '''describe that IItemLists have an attribute items that is a list. items = List( value_type=Object(schema=IElement), title=_(u"items"), description=_(u"""Physical representation of the list."""), required=False ) from persistent.list import PersistentList class ItemList(ItemStructure): '''fullfill the interface. Have an attribute items that is a list''' implements(IItemsList) items = PersistentList() Forms validate based on the schema (interface). But maybe you want to use FieldProperty also validate if the attribute is written from other python cold. All other classes have to do the same: Interface + implementation class ..Carsten ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
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?
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: > 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] Salt-weakness in zope.app.authentication passwordmanagers?
Hi there, to answer myself ;-) Uli Fouquet wrote: > Dan Korostelev wrote: > > Yeah, that's definetely a mistake! The hash needs to be generated > > using both salt and password. > > [snip] > > BTW, to fix it, we need to remember about migration of already stored > > hashes. I guess zope.app.generations will do the job. > > Yep, that's important and could cause trouble. Already stored passwords > could become invalid if we don't care for them and this could also be a > problem with generations, as here not only pure code would be concerned > but also data stored in the configuration. This problem is more serious than I thought in the beginning. We could update existing encrypted passwords, but we cannot say, where and how they are stored. Just think of SHA1 passwords mass-stored in some LDAP, RDBMS or a password file. The risk is, that no users from such databases could authenticate themselves anymore after an upgrade. I'd be glad to provide a fix for this, but I am undecided how we could support administrators best to upgrade their password bases. Currently, three (not mutual exclusive) approaches come to my mind: 1) the fixed password managers could be registered under different names. Support of the old ones could slowly run out and users could be warned, if they still use the old password managers. The old password managers then could be used as a fallback. This would weaken security (as two different hashes would allow one to authenticate with the same password), but not very much (you get a chance of 2:8**20 instead of 1:8**20 in worst case). Paranoid folks should be able to disable the fallback and expect complaints from their users. Default policy might be to disable fallback. 2) A commandline tool should be available, that can at least get old (encrypted) passwords and tell how they look hashed proper. Administrators had to take care for storing them in site.zcml, their LDAP or wherever they store passwords. 3) A commandline tool could also update existing ZCML files. This might fix the problems for most users. There might be smarter approaches. Any hints are very welcome. Best regards, -- Uli signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope3-Users] Next Step to Bug Resolution???
Hi Dan, On Sat, 2009-01-17 at 01:28 +0300, Dan Korostelev wrote: > Hi Tim. > > Unfortunately I didn't follow the discussion lately, so may be the > problem is no more, but... There has been a tremendous amount of help from folks like you. However there is still not a solution. I have been asked several times for a 15 minute overview. This is tough given the complexity but allow me to ask the question at a more basic level. I believe it is similar to the way I asked it last year, but here goes. I'm not going to address Field or Object here, just explain the basics. class DataStructure(Persistence): """abstract class""" class ItemStructure(DataStructure): """abstract class""" class ItemList(ItemStructure): u""" Logical list data structure, where each item has a value and can be referred to by a name and a positional index in the list. The list may be empty. """ items = List( value_type=Object(schema=IElement), title=_(u"items"), description=_(u"""Physical representation of the list."""), required=False ) class ItemTable(ItemStructure): u""" Logical relational database style table data structure, in which columns are named and ordered with respect to each other. Implemented using Cluster-per-row encoding. Each row Cluster must have an identical number of Elements, each of which in turn must have identical names and value types in the corresponding postions in each row. Some columns may be designated 'key' columns, containing key data for each row, in the manner of relational tables. This allows row-naming, where each row represents a body site, a blood antigen etc. All values in a column have the same data type. Used to represent any data which is logically a table of values, such as blood pressure, most protocols, many blood tests etc. Not used for time-based data, which should be represented with the temporal class HISTORY.. The table may be empty. """ class ItemSingle(ItemStructure): u""" Logical single value data structure. Used to represent any data which is logically a single value, such as a person's height or weight. """ * There are others and I left out the attributes and methods of these classes; with the exception of ItemList attribute 'items', where it is a zope.schema List but the value types are restricted to the schema described by IElement (also part of openEHR); but I think you get the idea. These classes are used as the base software for all openEHR applications. Of course the classes get more complex and deal directly with healthcare related issues. Now there are thousands of applications that will have data instance with attributes expressed in classes based on the above software that represent single (but complete) clinical concepts. But not all application user interfaces will use all available attributes of the concept. One may use an ItemTable and another an ItemList but they will both be valid in ANY application because the attribute represents a legal instance of ItemStructure. When that data instance is sent from application to another the receiving applications still needs to know the complete semantic context of when that data was collected.Think medico-legal, research and decision support over the lifetimes of patients and populations. So even if the user didn't see all the options in their GUI; it is still all contained in the data that was transfered. So how do I build my schemas so that Zope does the validation of nested schemas and even lets me use standard widgets? I hope this was less than 15 min. For those that want specific examples I can list a few. Cheers, Tim <> signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hi 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: > 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 Dieter > Betreff: 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. 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. 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. 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. Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Sat Jan 17 12:00:00 2009 UTC to Sun Jan 18 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sat Jan 17 20:53:28 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010871.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sat Jan 17 20:54:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010872.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sat Jan 17 20:56:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010873.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sat Jan 17 20:57:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010874.html Subject: OK : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sat Jan 17 20:59:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010875.html Subject: OK : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sat Jan 17 21:00:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010876.html Subject: OK : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sat Jan 17 21:02:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010877.html Subject: OK : Zope[2.buildout]-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sat Jan 17 21:03:59 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-January/010878.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py Hhm, pdb?!?
Tres Seaver wrote: > Hanno Schlichting wrote: >> Log message for revision 94810: >> Hhm, pdb?!? > >> Changed: >> U Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py > >> -=- >> Modified: Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >> === >> --- Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >> 2009-01-17 20:01:44 UTC (rev 94809) >> +++ Products.GenericSetup/trunk/Products/GenericSetup/tests/common.py >> 2009-01-17 20:41:54 UTC (rev 94810) >> @@ -53,7 +53,6 @@ >> for i in range( len( zipped ) ) >> if zipped[i][0] != zipped[i][1] >> ] >> -import pdb; pdb.set_trace() > >> print 'Found:' >> print fxml > > That breakpoint was inside an if block guarded by 'if debug:', which > shouldn't be set by any "real" test. I can put it back if you want to. I'm just accustomed to a strict "no-pdb"-policy in checked in code. Quite some repositories even enforce it via a post-commit hook. 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 )
