[Zope-dev] 2.2.0a1 won't work with query objects
Hi, all, I tried compiling 2.2.0a1 straight out of the box on Solaris 7. Everything worked great until I tried querying a tiny table or MySQL database. The following code causes Zope to prompt me for a login, and no matter what user name I use (even the superuser), it comes back "unauthorized." If I take out the section, my pages pops right up. Any ideas? Sincerely, T.J. Mannos Salt Lake Community College ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Distributed ZODB-Transactions
Heine Gregor wrote: > OK, I admit, I didn't tell you the whole truth. ;-) > The Backup-Server should not only backup one, but various > Zope-installations (sort of 'backup-central'). I would suggest that very soon, the "least intervention" principle would be to use ZEO, have a single ZODB backing multiple Zopes (that need not be serving the same site using SiteAcces) and then replicate the single StorageServer, perhaps hooking into the append as mentioned earlier. Good luck, Ethan Fremen [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Minor "bug"
Hi! I've just noticed with 2.1.6, that after clicking "Minimize" or "Full Sweep" on /Control_Panel/Database/manage_cacheGC, the resulting page is missing most Tabs and one has to click "Contents" to get all tabs. Maybe this is intentional, but it seems like (very) minor bug to me. Andreas -- Andreas Kostyrka | [EMAIL PROTECTED] phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H.| fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA http://www.euro.cauce.org/ | http://www.cauce.org/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subclassing LoginManager
At 06:02 PM 5/19/00 -0400, Dan L. Pierson wrote:
>LoginManager.LoginManager.validate. A rough sketch is like this:
>
>if req_has('__ac'):
>... handle cookie login ...
>
>if req_has('__ac_name') and req_has('__ac_password'):
>... handle explicit login ...
>
>if auth and lower(auth[:6]) != 'basic':
>... do basic authentication ...
>
>... climb up the acquisition hierarchy ...
>
>... try anonymous ...
LoginManager will behave just like your outline, if you give it a
BasicCookie LoginMethod, and a BasicAuth LoginMethod, in that order.
LoginManager does not climb up the acquisition hierarchy, as that is
properly the province of ZPublisher to do. It will provide the anonymous
user, if it is a top-level user folder.
>I know that the official way to do most of this sort of thing with
>LoginManager is by defining new LoginMethods, but I just don't see how
>to make LoginManager even try the LoginMethods at the correct time
>without overriding validate.
>
>Am I on the right track here?
Not as far as I can see. You shouldn't even need any custom LoginMethods,
the out-of-the-box ones should work just fine.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Subclassing LoginManager
OK, time for another Zen fix :-)
It looks like I've almost got PTK working with the latest
LoginManager. The remaining problem is that the login form doesn't
work. I've finally figured out why.
PTKBase.MemberFolder.MemberFolderBase.validate is much hairier than
LoginManager.LoginManager.validate. A rough sketch is like this:
if req_has('__ac'):
... handle cookie login ...
if req_has('__ac_name') and req_has('__ac_password'):
... handle explicit login ...
if auth and lower(auth[:6]) != 'basic':
... do basic authentication ...
... climb up the acquisition hierarchy ...
... try anonymous ...
I know that the official way to do most of this sort of thing with
LoginManager is by defining new LoginMethods, but I just don't see how
to make LoginManager even try the LoginMethods at the correct time
without overriding validate.
Am I on the right track here?
Dan Pierson
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding ZCatalog index programatically
R. David Murray writes: > I was just looking at the ZCatalog code to figure out how to programatically > add an index to a Catalog. I figured out how to do that fairly easily, > but the code I was looking at has me a bit mystified. The method > manage_addIndex is defined. The form that you use through the > management interface to add an index has a submit button whose name > is manage_addIndex:method. OK, that all looks like reasonable > magic (magic because I don't know exactly what happens when a button > gets marshalled as a method). The method is not marshalled but called with the remaining form fields as parameters. More precisely, Zope looks for the "method" starting from the action URL and then calls this method in the usual way with the form content as parameters. This is well documented somewhere (together with the other nifty ":" argument name suffixes. Unfortunately, I seem not to have a local copy of this document and therefore, cannot tell you where to find it, at the moment. The code, handling this, is in "ZPublisher.HTTPRequest.HTTPRequest.processInputs" (not easy to understand). Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Superuser ownership (was "Adding LoginManager at the root")
"Phillip J. Eby" wrote: > > At 05:12 PM 5/16/00 -0400, Jim Fulton wrote: > >"Phillip J. Eby" wrote: > >> > >> 2. The current implementation/usage of "manage_fixupOwnership" seems broken > >> to us, in that moving, renaming, and importing objects causes the current > >> user to silently take responsibility I should have remarked that the user is explicitly doing something. There isn't really anything solient about it. > for an entire object subtree. We > >> think this is unequivocally broken with respect to renaming, and there are > >> common use cases for which the current moving and importing behavior would > >> have to be considered broken. We propose that only copying and adding > >> should involve an implicit "take responsibility" action. > > > >I can agree wrt naming. I don't agree wrt import. Import is equivalent > >to copy. > > Consider the situation of someone with "development" and "production" > sites, exporting from one and importing to the other. Import is now > "lossy" with respect to responsibility. No, It's gainy, uh, or maybe switchy. :) > >Moving is close enough, IMO. > > If I make a copy of something on my desk, I expect it to not be the > original, so although I would expect it to work like the original, I could > understand that I would be responsible for the copy (since I made it). But > if I move something on my desk to the other side, I don't expect it to > suddenly stop working, unless there is something about where it was that > made it work. In that case, I would assume that moving it back would fix > it. But moving it back doesn't fix it, because the objects were actually > changed. When all you did was move them, changing objects irreversibly > seems just plain *wrong* to me. I just moved the document: I didn't even > *read* it, let alone modify it or sign off on it! You are slowly swaying me on this . I'll let Brian figure out if there is a consensus on this. > >> 3. The ability of the superuser to be responsible for objects should be > >> acquirable in some fashion, > > > >superuser can never be responsible, however, the same effect is > >had by making an object unowned. > > Hm. Perhaps in the proposed terminology, an "unowned" object could be > called an "irresponsible" object, which seems to have appropriate > connotations. :) :) > >> so that objects such as LoginManager and > >> GenericUserSource (which require objects to be created inside them for > >> bootstrapping) can permit "standard" Zope objects to be created within them > >> by the superuser. > > > >Why *must* this be done by the superuser? > > Because as far as I can tell, until it's done, superuser and nobody are the > only users that exist to do it, if you want a GUF, GUS, or similar object > as your root acl_users. You can't even make another user in a temporary > user folder, because if you copy the acl_users as superuser, you aren't > allowed because it would give the superuser responsibility. And if you > delete the root acl_users so that you can then have the "manager" user do > the copy, the manager can no longer log in, because he doesn't exist any > more! (Incidentally, this is another use case which suggests that moves > causing a responsibility change is wrong, since if they didn't do this, the > superuser could move acl_users to the root, assuming it was movable.) Hm. Interesting point. > >> Currently, this would have to be done by overriding > >> _setObject in these classes such that it doesn't call > manage_fixupOwnership. > > > >If you need to assure that all objects under some object are unowned, > >then that can be arranged. (Hint, grep for "UnownableOwner" in the sources.) > > We skimmed alot of the UnownableOwner stuff because it made our brains > ache. :) (All the darting back and forth between UnownableOwner vs. None > was confusing.) Upon re-reading, it seems to me that if one were to set > _owner = UnownableOwner in a class, it would ensure that anything contained > underneath that location would be unable to have ownership assigned to it. > Is that correct? Right, at least without low-level intervention. > >> 4. The SecurityManager API and ZopeSecurityPolicy have a shared design flaw > >> that could seriously impact performance when used with user objects which > >> are not part of the ZODB. Specifically, ZSP asks executing objects for > >> their "owner" objects, which causes a getUserById() hit, which can > >> potentially cause external database lookups... for every single DTML name > >> lookup! Further complicating things is that GenericUserSource and > >> GenericUserFolder may call back to this very same security lookup in order > >> to determine access to an SQLMethod or LDAPMethod needed to look up the > >> user! We propose a refinement to the addContext/removeContext that allows > >> the "responsible user" to be placed on the context stack, rather than > >> having it looked up later by the security policy. This could still have a > >> s
Re: [Zope-dev] ZServer Ftp Active mode through firewall
Shane Hathaway wrote: > > I did some research into this today. Note that this is actually a > problem with the Medusa server used by Zope. Thanks > 3) The only remaining solution would be to bind to the data port at > startup. However, the accept() call and the connect() call have a very > subtle difference: accept() creates a new socket, while connect() uses > the socket already created. So it would be possible to use that socket > once but it would be necessary to close it at the end of the transfer, > leaving subsequent connections in the same situation as before. If > connect() created a new socket instead, Medusa would work much better > and I bet wu-ftpd could be less convoluted. I don't think there is any > alternative to connect(). Yep. > I'm sorry I don't have a better answer for you. I really thought we > could solve this. I'm surprised the proxy acted so strangely for > you--there's no reason why it should be dealing with user permissions, > etc.; it should only pass the data from the client to the server (with > minor re-parsing along the way). Perhaps a different proxy will work > better. Part of the problme is that we need to be able to set different 'anonymous' roles based on where one comes from. This is supported by wuftpd and by Zope. When you pass everything through a proxy on the zope server host however, that capability is destroyed as the proxy is now the only client. We tried having the proxy set usernames, but then we need two users for each role; one for http and one for ftp. And we will have to rewrite the proxy code to send remapped usernames in a fashion that Zope can comprehend, as the current proxy name remapping doesn't work with Zope. Couple these problems with having to keep two different authentication schemes synced leads us off a cliff very quickly. >From the number of messages I located on the net regarding this issue it is clear that a number of people have tried this and failed, not discovering the true cause of the problem. The use of firewalls is quickly increasing and the problem will only get worse. Have you considered a C shared module to handle the seteuid issue? Maybe an option for those who really need it? Import only when permissions indicate that seteuid is to be used? Tahnks ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
Phillip J. Eby:
> In ZPatterns 0.4.0 and beyond, RackMountables will probably change their
> name to DynamicDataObjects, or DDO's for short. This is to reflect their
> new, wider scope, which does not require them to be mounted in a Rack to
> have their dynamic features. They will be able to have providers manage
> their data no matter where they are in a Zope application, so long as the
> DDO is in acquisition context of a ZDMFolder ("Folder w/Data Management
> Support") that has a ZDataManager plug-in registered for the DDO's meta_type.
This sounds amazingly flexible.
>
> I'm not actually real fond of the DDO term, because "Dynamic Data Object"
> doesn't quite do justice to what these things actually are. I am
> definitely open to suggestions for a better name. (Facade? PlaceHolder?
> InsideOutObject? ExternalDataObject? BrainInjectedObject?)
ZopeTupperware, AloofAttributeObjects, DataSkins :)
>
> Also, while I'm babbling about versions, it's important to note at this
> point that ZPatterns versions below 1.0.0 should be considered subject to
> change even with respect to developer-level API's. They get more stable as
> the number gets higher, which is why LoginManager changed a lot less
> between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between
> 0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump,
> due to the DDO stuff as well as the Indexes stuff. Predicates may even
> make it in, in some small way.
This is one of the reasons I am just looking a tinkering. But this is
definately is the future of instance data and data presentation in Zope.
All my best,
Jason Spisak
CIO
HireTechs.com
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544
Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission. Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZServer Ftp Active mode through firewall
Kent Polk wrote: > Now this gets really convoluted... :^( We have it up and running, > but user/permissions/role translation quickly turns into a really > bad nightmare. > > Why can't root launch ZServer and have port 20 permissions? jftpgw > has to do that to have active ftp work anyway. Why add yet another > Point of Entry/Confusion? As I mentioned earlier, why not have it > respond on port 20 if it has permissions, otherwise respond via > high port#?? > > What am I missing here? I did some research into this today. Note that this is actually a problem with the Medusa server used by Zope. 1) Zope will never have root privileges during normal operation (at least, it's not supposed to!) It uses root privileges to create the server sockets then drops them just before entering the main loop (z2.py). 2) wu-ftpd uses seteuid() to bind to the correct port. It has to call seteuid() every time someone makes an active connection. The current version of Python does not provide the seteuid() call, only the setuid() call, which is irreversible. 3) The only remaining solution would be to bind to the data port at startup. However, the accept() call and the connect() call have a very subtle difference: accept() creates a new socket, while connect() uses the socket already created. So it would be possible to use that socket once but it would be necessary to close it at the end of the transfer, leaving subsequent connections in the same situation as before. If connect() created a new socket instead, Medusa would work much better and I bet wu-ftpd could be less convoluted. I don't think there is any alternative to connect(). I'm sorry I don't have a better answer for you. I really thought we could solve this. I'm surprised the proxy acted so strangely for you--there's no reason why it should be dealing with user permissions, etc.; it should only pass the data from the client to the server (with minor re-parsing along the way). Perhaps a different proxy will work better. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
"Phillip J. Eby" a écrit : > Good point, but ordinarily one mixes RackMountable with another Zope class > such as SimpleItem.Item, or uses it as part of a ZClass. In either case, > Acquisition gets added in. SimpleItem.Item only subclasses ExtensionClass.Base, and I got an AttributeError on __of__ unless my RackMountable subclasses Acquisition.Implicit also. bizarre isn't it? > I'm not actually real fond of the DDO term, because "Dynamic Data Object" > doesn't quite do justice to what these things actually are. I am > definitely open to suggestions for a better name. (Facade? PlaceHolder? > InsideOutObject? ExternalDataObject? BrainInjectedObject?) what about "penguin" ? :-) > Also, while I'm babbling about versions, it's important to note at this > point that ZPatterns versions below 1.0.0 should be considered subject to > change even with respect to developer-level API's. They get more stable as > the number gets higher, which is why LoginManager changed a lot less > between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between > 0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump, > due to the DDO stuff as well as the Indexes stuff. Predicates may even > make it in, in some small way. Have you got an idea of when 0.4.0 will ship ? regards, jephte clain [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] long-running external python method
I have woes calling a long-running external class method. The external method must be called after the class instance is constructed, because the method modifies class properties. Modifications are done in the external method using python's urllib pointing to the object's manage_edit DTML method. This is done to keep the class updated with progress of this long running process. The process, by the way, is started in a daemon thread so my class_add DTML method can return and (re)display progress. I know I'm getting tangled up in DTML namespaces. For instance, I know I can do the following inside my class_add DTML method: where ZDeformStart is the external method. But I can't do this because it's a gamble to assume the class instance is created before the external method tries to call the instance's manage_edit! I don't think the class is committed until the final /dtml-with. I have tried synching the daemon thread in the external method, but this conflicts with Zope pickling... I would like to do something like: This ensures the class is committed before ZDeformStart is called, but this returns an AttributeError on ZDeformStart. I don't know how to call this method outside the "with" constructor. Could someone offer a zope-line? David Mika GE Corporate Research & Development k1-mb 237 One Research Circle Niskayuna, NY 12309 Ph: 518 387 4223 Fx: 518 387 6232 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns framework improvements
At 09:46 PM 5/19/00 +0400, Jephte CLAIN wrote:
>Some thought about RackMountables: they should subclass
>Acquisition.Implicit for bobotraversing to work. indeed, the
>__bobo_traverse__ code says:
>
>return getattr(ob, 'aq_base', ob).__of__(self)
>
>ob has the __of__ attribute only if it subclass an extension class
>(Acquisition.Implicit is an easy choice)
Good point, but ordinarily one mixes RackMountable with another Zope class
such as SimpleItem.Item, or uses it as part of a ZClass. In either case,
Acquisition gets added in. I prefer to keep the base class as free as
possible of things that will be mixed in later to avoid repeated
inheritance. Also, for what it's worth, future versions of RackMountable
will define their own __of__ method, as it will be required to support
placement of rackmountable-ish objects in places other than racks.
>in AttributeProviders.py, around line 199, definition of
>_DelAttributeFor is bogus. Instead of:
Noted and fixed for next release.
>It is desirable for me to enumerate the objects stored in the racks for
>a specialist. Because the __readableStorage is not accessible from
>derived classes (magic of ExtensionClasses ???), I can't add that
>behavior without patching Rack.py
>
>I'm thinking of a method 'rsValues' that enumerate values in the
>readableStorage. In Rack.Rack:
>
>def rsValues(self):
> """rsValues like 'readableStorageValues'
> why on earth are there __readableStorage and __writableStorage ???
> """
__readableStorage and __writeableStorage are designed to prevent
side-effect transactions occurring. It's a little bit tricky, but
basically __readableStorage doesn't create a storage if it hasn't already
been created - it instead returns an empty dictionary. __writeableStorage
creates the storage if it doesn't exist. Thus, operations that only intend
to read data from the storage don't cause a write transaction when the
storage doesn't yet exist.
> values = []
> slots = self.__readableStorage.values()
> for slot in slots:
> # the following took from retrieveItem
> item = slot[SelfKey]
> item._setSlot(slot)
> item._clearPerTransactionCache()
> # associate the rack to the item
> item._setRack(getattr(self, 'aq_inner', self))
> ## the above line could be written
> # item._setRack(self.aq_inner)
> ## if racks objects where always wrapped.
> values.append(item)
> return values
>
>Or is it best to create a catalog in the specialist that index all
>objects stored in the rack as they get added?
Yes, that is the best route for the current version. Future versions will
support an "Indexes" tab for plugins that manage search and retrieval.
This tab will be on both Specialists and Racks, as well as on the new
ZDataManager class that allows Providers and Indexes on objects stored in
Folders or other "normal" ZODB locations.
>The default ZODB storage should give the ability to enumerate the
>objects, even if it does not belong to the standard "interface" of the
>rack.
Something like that will be included, but it will be in the form of a
plugin that goes on the Indexes tab, which the Rack can call. At that
point, searching/enumerating *will* be part of the Rack interface.
>I understand now that the RackMountable is only a placeholder class, and
>that attributes and sheets are managed by AttributeProviders and
>SheetProviders, right?
That is correct. RackMountables are like abstract classes that only have
domain knowledge (application-level intentions) with no data storage
implementation knowledge.
In ZPatterns 0.4.0 and beyond, RackMountables will probably change their
name to DynamicDataObjects, or DDO's for short. This is to reflect their
new, wider scope, which does not require them to be mounted in a Rack to
have their dynamic features. They will be able to have providers manage
their data no matter where they are in a Zope application, so long as the
DDO is in acquisition context of a ZDMFolder ("Folder w/Data Management
Support") that has a ZDataManager plug-in registered for the DDO's meta_type.
I'm not actually real fond of the DDO term, because "Dynamic Data Object"
doesn't quite do justice to what these things actually are. I am
definitely open to suggestions for a better name. (Facade? PlaceHolder?
InsideOutObject? ExternalDataObject? BrainInjectedObject?)
Also, while I'm babbling about versions, it's important to note at this
point that ZPatterns versions below 1.0.0 should be considered subject to
change even with respect to developer-level API's. They get more stable as
the number gets higher, which is why LoginManager changed a lot less
between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between
0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump,
due to the DDO stuff as well as the Indexes stuff
[Zope-dev] Zope 2.2.0a1 problem in select_trigger
I just installed 2.2.0alpha1 onto an NT machine that already had
two copies of Zope running happily on it. The new copy of Zope
refuses to start with the following traceback:
Traceback (innermost last):
File "", line 1, in ?
File "z2.py", line 524, in ?
import ZServer
File "D:\zope2\ZServer\__init__.py", line 123, in ?
from HTTPServer import zhttp_server, zhttp_handler
File "D:\zope2\ZServer\HTTPServer.py", line 116, in ?
from HTTPResponse import make_response
File "D:\zope2\ZServer\HTTPResponse.py", line 97, in ?
from PubCore.ZEvent import Wakeup
File "D:\zope2\ZServer\PubCore\ZEvent.py", line 91, in ?
Wakeup=trigger().pull_trigger
File "D:\zope2\ZServer\medusa\select_trigger.py", line 103, in
__init__
a.bind (self.address)
File "", line 1, in bind
socket.error: (10048, 'winsock error')
I ran it under pdb and it is trying to bind a socket to 127.9.9.9, port
1. Zope 2.1.6 had this code inside a loop so that if the bind
failed it subtracted 1 from the port number and then tried again until
it found a free port (or gave up after trying 50), but the loop has
been removed in the new release.
(copied to the Collector)
--
Duncan Booth [EMAIL PROTECTED]
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Slow startup times
> A number of times the subject of slow startup times has been raised,
> because it's particularly annoying while developing python products.
> I've always found it very snappy (restart in less than 4 seconds), but
> yesterday I found a machine where it was much slower (20 seconds).
>
> With the patch below, all my machines can now restart Zope in under 3
> seconds ;-)
It now takes my zope on localhost about 5 seconds to restart, but
that is much better than the 36 seconds it took before. Thank you
very much for this patch.
--
Duncan Booth [EMAIL PROTECTED]
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Slow startup times
> A number of times the subject of slow startup times has been raised,
> because it's particularly annoying while developing python products.
> I've always found it very snappy (restart in less than 4 seconds), but
> yesterday I found a machine where it was much slower (20 seconds).
>
> With the patch below, all my machines can now restart Zope in under 3
> seconds ;-)
It now takes my zope on localhost about 5 seconds to restart, but
that is much better than the 36 seconds it took before. Thank you
very much for this patch.
--
Duncan Booth [EMAIL PROTECTED]
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPatterns framework improvements
sorry, I can't reproduce the error I talked about yesterday. All the insights given by philip has lighted up my path :-) There are four points I want to discuss: *** Some thought about RackMountables: they should subclass Acquisition.Implicit for bobotraversing to work. indeed, the __bobo_traverse__ code says: return getattr(ob, 'aq_base', ob).__of__(self) ob has the __of__ attribute only if it subclass an extension class (Acquisition.Implicit is an easy choice) *** in AttributeProviders.py, around line 199, definition of _DelAttributeFor is bogus. Instead of: def _DelAttributeFor(self,client,name): return self.aq_parent.aq_parent._SetAttributeFor(client,name) it should read: def _DelAttributeFor(self,client,name): return self.aq_parent.aq_parent._DelAttributeFor(client,name) *** It is desirable for me to enumerate the objects stored in the racks for a specialist. Because the __readableStorage is not accessible from derived classes (magic of ExtensionClasses ???), I can't add that behavior without patching Rack.py I'm thinking of a method 'rsValues' that enumerate values in the readableStorage. In Rack.Rack: def rsValues(self): """rsValues like 'readableStorageValues' why on earth are there __readableStorage and __writableStorage ??? """ values = [] slots = self.__readableStorage.values() for slot in slots: # the following took from retrieveItem item = slot[SelfKey] item._setSlot(slot) item._clearPerTransactionCache() # associate the rack to the item item._setRack(getattr(self, 'aq_inner', self)) ## the above line could be written # item._setRack(self.aq_inner) ## if racks objects where always wrapped. values.append(item) return values Or is it best to create a catalog in the specialist that index all objects stored in the rack as they get added? The default ZODB storage should give the ability to enumerate the objects, even if it does not belong to the standard "interface" of the rack. *** I understand now that the RackMountable is only a placeholder class, and that attributes and sheets are managed by AttributeProviders and SheetProviders, right? any comments? jephte clain [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Slow startup times
A number of times the subject of slow startup times has been raised, because it's particularly annoying while developing python products. I've always found it very snappy (restart in less than 4 seconds), but yesterday I found a machine where it was much slower (20 seconds). With the patch below, all my machines can now restart Zope in under 3 seconds ;-) http://classic.zope.org:8080/Collector/1260/view Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] What to return to a document and how to access it
Hi,
These are defined in a product:
#---
class SomeClass:
"""DocString"""
def __init__(self):
"""DocString
pass
SomeDoc = HTMLFile('Some', globals()) # Some.dtml -> DTML-document
def SomeMethod(self, values = '', REQUEST): # the values put into the method
isn`t important now
"""Docstring"""
a = SomeClass()
a.values = {}
a.values['1'] = [1,2,3,4,5]
a.values['2'] = [323,3,4,41,25]
a.plain_string = 'test'
a.list = [32,435,21,9]
return self.SomeDoc(self, a)
#---
How can I access the returned object in 'Some.dtml'?
I`ve tried stuff like:
1: ( I want the plain_string-property of the a-object )
2: ( the same )
3: ( the same )
4.
I get a NameError and KeyError etc. It works if I return a dictionary with
keys pointing to single values, but I want to return a whole object, and do
stuff like :
#---
#---
What I want in HTML :
test
1
1
2
3
4
5
2
323
3
4
41
25
32
435
21
9
If somebody could show me how to access the stuff returned in the method
above, I`d be grateful.
Thomas
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Oracle BLOBS how to ?
Hello all, I am developping an application using Zope (version 2.1.6) and Oracle 8.1.6 (8iR2) on Linux platform. I use ZOracleDA 2.2.0b1 and DCOracle 1.3.1b1. It seems that stability problem is fixed (as far as I have tested) but I still have problems retrieving BLOBs from the database into a HTML page. Is there somewhere a HOW-TO to get and display a BLOB (it is a GIF image) in an HTML page ? I have the following table: CREATE TABLE test_picture (name CHAR(50), picture BLOB); I imported (using sqlldr) a single GIF image into the table with name 'lady'. I created a ZSQL method (called TestPicture) to retrieve this image (SELECT picture FROM test_picture WHERE name = 'lady'). When I test this query I get a -24813 error from Oracle and if I use a DTML method to display the picture I get an empty image. The DTML method is: Thanks for your help Best regards Joseph Canedo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
