By the way -- is it me, or is the current Import/Export interface
broken? I tried to select multiple objects to export, but I can only
get the first one to actually be exported.
Nope, that's the way it's supposed to work, I think :-)
It's why I got happy when I saw your earlier post; it
Phillip J. Eby wrote :
Get rid of the "id_user" DTML method and add the following
to a SkinScript method inside your UserSource:
WITH QUERY SQL_id_user(username=self.id) COMPUTE id_user
You should then be able to do "AUTHENTICATED_USER.id_user" to retrieve the
attribute.
I had to update
Hmm.. anybody seen this?
-steve
cc -fpic -I../Components/ExtensionClass/src -I../Components/BTree -I./ZODB -O -pipe
-D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5
-DHAVE_CONFIG_H -c ./../Components/BTree/BTree.c
./../Components/BTree/BTree.c: In function
Hi,
I have imported about 2500 xml files in ParsedXML objects through the
use of :
manage_addProduct['ParsedXML'].manage_addParsedXML(id, '', xmlString)
This works perfectly.
But when trying to browse the folder containing the ParsedXML instances,
a whole lot of memory is used by Zope and it
Hi Zopists,
I have now problem with executable content where this() is called.
My problem:
I have this structure in ZODB
/
|_ acl_users (Zope default)
|_ dalmatin (ISNG Folder) * ownes user who is in role Manager from /dalmatin/acl_users
|_ acl_users (Modified LDAPAdapter)
|_
Ricardo Bermell writes:
Zope (started from a shell) in OpenBSD gets locked
too easyly because of the low default limit for
open file descriptors (64).
Most operating systems allow you to increase this number
(either at runtime or through a kernel recompilation).
Dieter
Karl Anderson a crit :
Hm, it's been pointed out to me that the inefficiency of the get_size
method of ParsedXML is compounded with many instances because the
standard management interface uses it.
It's possible that some stuff isn't getting garbage collected until
the transaction is
