[Zope-dev] Patch: Enable Unicode in ParsedXML
Hi Patrick, this is my first post to this list so I'm not sure this is proper way to submit a patch. If it is not, please direct me to the correct place. This patch enables Unicode characters in qualified names for XML documents stored with the ParsedXML product. First, thanks for the patch! Second, ParsedXML is not a core Zope product (normally you should have to install it separately). zope-dev is not exactly the right list to post for add-on products most of the time. Ususally there is a README.txt in such a separate product containing contact information for patches, etc. I just checked the ParsedXML README and the information there is quite out of date and contains a couple of stale links ... I will bug Martijn Faassen as he is the current maintainer ;-) And, no, the zope core collector is no good place for it. Cheers, Clemens ___ 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] List of bugs which can be closed
Maik Jablonski writes: Hi, there are some bugs in the Zope-Collector which IMHO can be closed. [...] Not up2date anymore: http://zope.org/Collectors/Zope/591 http://zope.org/Collectors/Zope/943 and: http://zope.org/Collectors/Zope/599 (if someone minds...) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] ZPT in Zope Products
Hi Wyatt,
from Products.PageTemplates.PageTemplateFile import PageTemplateFile
def manage_addMyContainerForm(self, REQUEST):
pt = None
if self.meta_type in ['ContainerType1', 'ContainerType2']:
pt = PageTemplateFile('zpt/addMyContainerForm', globals())
else:
pt = PageTemplateFile('zpt/containerError', globals())
return pt.pt_render()
I guess the problem is that the page template file is called without
acquision context. Usually a page template file is a class attribute of
a class which knows about acquisition.
You could mange in the right context via
return pt.__of__(self).pt_render()
but I am not sure if this will fly.
Cheers,
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] Catching (external database connectivity) specific exceptions
Chris Withers writes: Clemens Robbenhaar wrote: Hm, figuring out the right exception actually the problem; if the data base connector would raise an exception of a certain type due to unability to connect I could catch these and let the others pass. Which DA are you using? It _should_ do that... ZMySQLDA - raises MySQLError and OperationalError from module MySQLdb (so far I have seen those at least ;-) Unfortunately I am not able to figure out the interesting ones so quickly by experimenting, because I cannot think about (or even reproduce) everything that may actually fail. The specifc DA you are using should subclass all it's exceptions from a base exception. ZOracleDA does this the right wya, fro mwhat I've seen... But it is a base exception class in ZOracleDA, however. Thus the product using it need to explicitely import this exception, and thus explicitely depend on the used relational database; code needs to be rewritten if one exchanges the external data base. (Well, if one uses something ambitious like oracle, sure there are more implicit dependencies in the used sql statements so one cannot simply switch to something e;lse anyway ;-) Maybe the DatabaseError class could remain in the DA.py, so specific data base connections could reuse this exception type? Sounds like a plan, now you jus thave to persuade the DA authors to start using it ;-) Well, um, yes, at least I am asking if it makes sense to keep the exception DA.DatabaseError in the code, even it it is not yet / no longer used. I see DA-maintainers are not all rushing out for using it, however ... product to use this exception now? (btw: does somebody know, if Zope3 would maybe have such an external data source connection specific exception?) Ask on [EMAIL PROTECTED] Well, I guess I should first read the Zope3 wiki ;-) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Catching (external database connectivity) specific exceptions; was: Pointless exception re-raising in DA.py
Chris Withers writes: Clemens Robbenhaar wrote: Ok, if this is the proper dance to catch such exceptions with Zope without risking ZODB corruption I will go with it. So far I have not been sure, that ConflictError is the only type needing special treatement in these cases. Well, the PROPER dance would be to only catch exceptions that you're happy to ignroe from your database. You should be able to find those otu fairly quickly. Any new ones htat come along later probably want to be looked at by you before being automatically ignored... Hm, figuring out the right exception actually the problem; if the data base connector would raise an exception of a certain type due to unability to connect I could catch these and let the others pass. Unfortunately I am not able to figure out the interesting ones so quickly by experimenting, because I cannot think about (or even reproduce) everything that may actually fail. However, looking at the code this thread started with: Catching all exceptions in a certain (relaively high level) place and transforming them into something else does not really help a lot there; this may catch real programming errors as well. So I finally got the point why the try: except: block there should go away. I guess the specific data base connector should raise that DB-failed specific exception, instead, Unfortunately there is no sich general exception for it. (such as java has as java.sql.SQLException ... often not very informative, but at least one knows its from the data base.) Currently I am bound to hard wire the exception type the specific data base connection raises in my code and have to change the code if I would change the underlying data base. Maybe the DatabaseError class could remain in the DA.py, so specific data base connections could reuse this exception type? Or it is much to late to introduce such an exception type, as none of the supporterd of a data base connection product will rewrite their product to use this exception now? (btw: does somebody know, if Zope3 would maybe have such an external data source connection specific exception?) Cheers anyway, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Pointless exception re-raising in DA.py
Hi Chris, In Shared/DC/ZRDB/DA.py, Line 399 of Zope 2.6.1 and line 419 in 2.7.0, there's this rather pointless lump of code: try: DB__=dbc() except: raise DatabaseError, ( '%s is not connected to a database' % self.id) ...which only serves to mask the real cause of the problem when trying to obtain a connection. I remeber I made a collector issue about that liens of code: http://www.zope.org/Collectors/Zope/927 Previously this has been a string valued exception. Actually I like it to be an exception of a certain type now, because I can now selectively catching this DatabaseError and distinguish it from other errors. No need for a evil bare except. The reason is that I would like to treat errors when accessing an external data base different from other errors; often the data obtained there is only optional to the page, so I don't want to show usered the error page in this case, only to fill up doem slot with sorry, that certain piece of information is not availabe, because our sql data base sucks. I see Your point. However is there any chance that dbc() does raise something more specific? I am afraid it does not. If it does not, I would have to go back to an evil bare except ... Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Pointless exception re-raising in DA.py
Hi Chris, [...] ...this is an application level decision. The code currently makes it very easy, but at the expense of debugging any unexpected exceptions that code throws. While relational data may be optional for you, for many people it is ESSENTIAL, and is used for things like their auth details, content storage, etc. For them, this piece of code causes MAJOR suffering, especially for intermittent failures where you can't just insert a print_traceback and try again ;-) Ok, understand (I guess ;-) [...] If it does not, I would have to go back to an evil bare except ... I wouldn't if I were you: try: *your zsql method except ConflictError: raise except Exception: return sorry, that certain piece of information is not availabe, because our sql data base sucks Ok, if this is the proper dance to catch such exceptions with Zope without risking ZODB corruption I will go with it. So far I have not been sure, that ConflictError is the only type needing special treatement in these cases. Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Schizophrenic ObjectManager?
Hi Ian,
Now, I want to have it also contain objects of type 'B', but displayed and
managed through a separate tab in the ZMI. If I click on the Contents tab
of an instance of F, I get the list of contained A-type objects, with cut,
copy, paste, delete, etc. If I click on another tab named, say,
OtherStuff, I want to see exactly the same kind of contents-list
management page, but for contained B-type objects.
I'm thinking that I might try having F contain an instance of ObjectManager
as a property, and delegate all B-managing functionality to that. Management
of A would be handled through F's inherited ObjectManager behavior. What
concerns me is that the encapsulated second ObjectManager wouldn't have a
container in the usual way, and that could seriously mess up acquisition.
Another possibility is to maintain only one collection, but to create the
illusion of two separate collections by having two copies of the contents
('manage_main') page, each modified to display only one kind of child.
The second alternative works, but You need to maintain two separate
copies of the manage_main DTML form the ObjectManager ... currently
Silva does exactly this (except it filtered out some objects by the id,
not the type).
The downhill is that one has to maintain the copies from the
ObjectManagers DTML, which is not very difficult, but may create some
dependency to the used Zope Version.
We have not found a better stable, reliable solution so far.
An alternative I am currently testing is to have two special attributes
emulating the ObjectManager to the 'manage_main', as You propose in the
first alternative. However You are right: this messes up management of the
ObjectManager items with acquisition ;-)
The trick is not to use a full ObjectManager attribute but only
something that looks like an ObjectManager to the manage_main, but does
nothing otherwise. Thus it does not get messed up too much as the object
cannot do a lot.
Currently manage_main only uses the objectItems method, so I
try only to override this. The result looks like:
class ObjectStub(Acquisition.Implicit):
a stub filtering out objects of a certain type
def __init__(self, meta_type):
self._my_meta_type meta_type
def objectItems(self):
return [ x for x in self.aq_parent.objectItems() \
if not x[1].meta_type==self._my_meta_type ]
# manage_main will use 'objectItems' from this object
# acquire the rest from the parent
manage_main = ObjectManager.manage_main
class MyContainer(ObjectManager, ):
special container class for A and B objects
all_meta_tpes = ('A','B')
# list object of type A
object_stub_a = ObjectStub('A')
# list object of type F
object_stub_b = ObjectStub('B')
def manage_main(self):
list only A objects
return self.object_stub_a.manage_main()
def manage_main_b(self):
list only B objects
return self.object_stub_b.manage_main()
manage_options = ObjectManager.manage_option + \
({'label':'Contents B', 'action':'manage_main_b'}) + \
... other tabs here
Sure there are some missing security declarations, (at least
manage_main_b is public ;-)
Also its not exactly my implementation, so it may contain some typos
when I have translated' it from my use case.
I am not sure if this is really a good idea, however.
This avoids copying around a pretty involved DTML file, but it
seems to create even more subtle dependencies ... e.g. it will certainly
break when mix in OrderedSupport (from 2.7, I have tested the snippets
above only with 2.6.4)
Another drawback of either the approaches is that after evert action
(rename, copy, etc) one ends up in the contents tab listing A (because
this is the manage_main), even if remaining, copying, etc in tab B.
I do not know if it helps, but maybe its at least entertaining ;-)
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] help me convert from j2ee to zope
Hi Ryan,
I am not certain if this is the right mailing list here, because
zope-dev is for the development _of_ Zope, not the development of
products _with_ Zope.
However if this thread starts to assemble a survey comparing Zope to
J2EE, this may be interesting for the Zope development, especially if
there are things in J2EE which may inspire Zope, or converse there are
Zopish ways which provide a better solution than J2EE for some problems.
I would like to stop developing with JBoss and convert to Zope.
I have been able to figure most things out using the Zope website but I have
a few questions...
The majority of my code was in EJB's. So I am trying to create Zope products
to replace them.
What kind of naming service is available within Zope? For example, how can I
get a reference to one object from another object within Zope? This would be
the equivalent of a local interface in J2EE. In JBoss I would use a session
bean as the remote user interface and it would manage entity beans. So in
Zope if I have a non-persistent object as the XML-RPC published user
interface, how can I have it access persistent objects within Zope?
Usually You should have some persistent object around by the Zope
framework when handling request. If doing an XML-RPC call You are already
talking to some persistent object given to You by the ZPublisher. I am
not sure what is the appropriate equivalent of a session bean in J2EE if
looking at Zope.
Inside any persistent object You should be able to
get other objects by calling unrestrictedTraverve('/path/to/object') if You
know the path to the object. Alternatively You could use a catalog to
look up objects if You are not sure where the objects are ... as the
catalog is a persistent object itself this means You need a globally
available catalog for Your application which You know You can look up in
a certain location ...
How can I create new objects programmatically in Zope? In J2EE I would get
get a home interface to a bean and then call a create method on it to create
the bean. I know how to create new objects using ZMI in Zope, but I need
objects to be created through remote calls from clients. For example if I
had objects that represent tasks in Zope, I need the clients to be able to
create and delete tasks. How do I do that?
There are factory methods for nearly all persistent objects. They are
registered in the context.registerClass call in the __init__.py of the
corresponding product (normally). These methods then are available via
the manage_addProduct attribute on every folder object; i.e. for
adding a Page Template (which is a class defined in the PageTemplates
Product) programatically You say:
folder.manage_addProduct['PageTemplates'].manage_addPageTemplate('template_id',
template_content)
where folder is the object which should contain the new page
template, and template_content is a string containing the contents of the
new template.
I've read all the documentation I can find on the web site, so if I've
missed something please point me to it.
Another source of inspiration is to install products which seem to do
something similar what You want and try to figure out how they did it.
(I personally prefer Silva for rather obvious reasons ;)
Cheers,
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] Resolved security-related collector issues for the public?
[...] there were several security-related fixes in the collector (and the collector-mailing-list) in the last days. Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc. At least for the resolved issues the fixed are public available from the CVS (maybe even together with log messages). Sufficiently skilled people thus can reconstruct the security issues from the changes; I feel there is no point for hiding them any longer. On the other hand admins may be less pressed to upgrade if they look at the current available list of fixes and find none which hurts them in their setup ... for example I do not have untrusted users able to write malicious Python Scripts on my site (I guess ;-), and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free to blow my site with one of the not yet published issues. my 2 cents, Clemens btw: it does not look like either zope.org nor zope.com has been upgraded yet? The find-support still looks quite public ... ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Resolved security-related collector issues for the public?
Jamie Heilman writes: Clemens Robbenhaar wrote: malicious Python Scripts on my site (I guess ;-), and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free Actually... unless you've altered the ZMI and HelpSys, you do use dtml-tree ...and HelpSys is publically traversable by default. Thanks for the clarification. I just tried to argue from a rather ignorant point of view ... I could argue some more about why these issues look not so dangerous to me, but even if I try hard, I cannot be so ignorant ;) Actually I only tried to point out that if someone would tell me there is another yet not published issue that would allow to read the password of my users TTW or the like, this would make me upgrade even in very ignorant mode. However when obscuring these issue this will ignorant (or just busy) admins not help a lot; they will upgrade after these issues are published, not after the fixes are released ... meanwhile black hats checking with the CVS may have their exploits applied already. About the current discussion of a security (non-)disclosure policy: I would be happy with a policy which makes security issues public if a fix from the public CVS is available. (Well, I am running Zope form the CVS, so my position is maybe a little biased ;-) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] 2.7 management_page_charset cannot be callable anymore
Brian Lloyd writes:
If you or Hajime can send me a patch against the current 2.7
branch, I'll make sure they get in before the beta is cut (or if
either of you are committers it is also fine to checkin yourselves
to the Zope-2_7-branch and head and let me know when its done).
Here is a patch that solves the issue with manage_page_charset not
beeing called if it is a method instead of a string-valued attribute:
Index: lib/python/App/dtml/manage_page_header.dtml
===
RCS file: /cvs-repository/Zope/lib/python/App/dtml/manage_page_header.dtml,v
retrieving revision 1.12
diff -w -u -r1.12 manage_page_header.dtml
--- lib/python/App/dtml/manage_page_header.dtml 22 Dec 2002 17:53:57 - 1.12
+++ lib/python/App/dtml/manage_page_header.dtml 15 Jan 2004 17:17:50 -
@@ -5,7 +5,7 @@
dtml-call REQUEST.set('management_page_charset','iso-8859-1')
/dtml-unless
meta http-equiv=content-type
content=text/html;charset=dtml-management_page_charset;
-dtml-call
RESPONSE.setHeader('content-type','text/html;charset='+management_page_charset)
+dtml-call
RESPONSE.setHeader('content-type','text/html;charset='+_.render(management_page_charset))
titledtml-if titledtml-title;/dtml-if/title
dtml-let ag=REQUEST.get('HTTP_USER_AGENT', '')
is_nav4=ag[:9] == 'Mozilla/4' and _.string.find(ag, 'MSIE') 0
I have not found any bad side effects after the patch, but I am not
very experienced with the soemwhat arcane DTML hacks, so it would be nice
if someone else does some testing with it.
At least it fulfills the requirements that manage_page_charset is
called if it is callable, and thus recovers Formulator.
What I am not certain about is if this reopens some XSS-security holes
the original change intended to close. However as long as one does not
have an utterly broken manage_page_charset method I cannot see why
this should happen.
Oh, I see Martijn already responded to the posting, so its maybe
superfluous anyway.
Cheers,
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] Re: 2.7 assertion with CVS of that morning two days ago
Hi Robert,
Hi Tres,
Adding 'guarded_hasattr' to the list of items wrapped items did not help.
I guess You have taken Tres too literally. I did the same (i.e. adding
the string 'guarded_hasattr' to the _NEED_WRAPPING list) and could
reproduce Your issue. After wandering through the code a while I think
Tres meant the function guarded_hasattr to be registered under the
name hasattr ...
I do not really understand what happens.
I don't either, but the follwing works for me :)
diff -w -u -r1.1.2.2 Implementation.py
--- AccessControl/Implementation.py 12 Jan 2004 23:58:39 - 1.1.2.2
+++ AccessControl/Implementation.py 15 Jan 2004 18:38:34 -
@@ -92,7 +92,7 @@
from DocumentTemplate import DT_Util
from ZopeGuards import safe_builtins
-_NEED_WRAPPING = ('max', 'min', 'iter', 'enumerate', 'sum')
+_NEED_WRAPPING = ('max', 'min', 'iter', 'enumerate', 'sum', 'hasattr')
for k, v in safe_builtins.items():
if k in _NEED_WRAPPING:
Chers,
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] ZServer HTTP 1.1 support
Hi Paul, I cannot answer Your original question: I noticed this in ZServer/README.txt (zope 2.6.2): HTTP 1.1 support is ZServer is incomplete, though it should work for most HTTP 1.1 clients. Anybody know what specifically is incomplete? but instead a complete random off remark: In particular, some people on my team asked me if zserver supports persistent connections, and I didn't know how to answer. I'm looking now at HTTPServer.py and the docstrings suggest that it does ... yes? no? You can try out yourself: connect to the Zope server via telnet and type in: GET / HTTP/1.1 Host: localhost The server should serve the page, and if it supports persistent connections, if should not close the connection, so You can type in the request again (if You type fast enough to finish before the timeout ;-) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 2.7.0 b3 regressions
1.) absolute_url(relative=1) behaves different -- 'relative' was changed from 'relative to site object' to 'relative to server root'. This is an API change and breaks Products like CMF. See http://zope.org/Collectors/Zope/809 I propose to revert this change. +1 from me. The original proposal has been to implement a separate method for this; maybe this should be done insetad. I thought the point to break backwards compatibility and to get rid of all the old cruft has been choosen to be Zope3, not Zope2.7, isn't it ? ;-) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: Zope 2.7.0 b3 regressions
[...] Please be careful with method names that might already be in use in some products. Google says Silva uses a getVirtualRoot() method. Why not using REQUEST variables? ... which is defined in an adapter-style class which is not implementing Traversable itself, so there is no conflict here. But thanks for checking this, anyway. :) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] session concurrency
Hi Santi, I've a product, http://zetadb.sourceforge.net, that uses SESSION extensively. I've just discover, unhappiness, that there are some problems when SESSION object is changed at the same time in two diferent python scripts (using frames). The two frames are changing diferent keys of the SESSION object, but at the end the whole SESSION object is saved, I think, so one of the two objects losses its SESSION data Anybody knows any workarround about this? I guess this happens because the SESSION is stored with a low conflict resolution in the TempFolder. You should be able to switch the conflict resolution in the temp folder to something more strict, which may increase the number conflict errors a lot. There have been a thread which may tell You how to do this on this list in March(?) of this year; seaching the mailing list archive for LowConflictConnection or something similar may help. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 doesn't know enough mime types.
Hi Romain, Yo, Zope doesn't know enough mime types, and there's no easy way to add them add runtime since you removed the add_type(...) method from mimetypes.py Who is you which has removed the function? I guess mimetypes is a core python module ... Anyway if You feel the need to add content types to the global mimetypes map, You can do this manually in Your custom product __init__.py, e.g.: from mimetypes import types_map types_map['.ra'] = 'audio/x-pn-realaudio' # etcetcetc I guess this is not worse than letting Zope to the patches. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] hanging unittests, was: Functional testing of export/import?
... just a random remark: [...] Also I've found that if there's an error in your class' setUp(), it can cause the test to hang and never show you a traceback. I have run into a similar problem; this seems to be caused by the (usually reasonable) behaviour of the pyunit not to call the tearDown method of a test faiming in setUp. Unfortunately in the context of unittesting Zope this results in a pending connection if the connection happends after the get_transaction().begin(). After few tests, all availabe connections seems to be busy and the test hang. I have been able to fix this for my local tests by surrounding the code in the setUp with an 'try: ... excecpt: block, where the except: block aborts the transaction before reraising the exception. This fixes the issue with the hang; one gets plain tracebacks telling what went wrong in the setUp. Looking at the more sophisticated structure of the CMF-tests this may be a bit tricky to apply this patch there. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Renaming a product
Hi Morten, Hi all, does anyone know how to rename a product, so that instances of the product stored in ZODB will work (with the new name) after the rename? I assume the problem is that the product is named A should be renamed into B in such a way that all instances of class Product.A.Foo are of type Product.B.Foo afterwards. The only way I could think of is to write a migration function for each class in Product A, which gets an instance e.g. of class Products.A.Foo and returns an instance of class Products.B.Foo which is suitable to replace the other instance. If all Your classes are stored via some standard implementations of OFS.ObjectManager, it should be easy to recurse from the Zope Application root and descent into all folders, converting all object of the old product into those of the new product via the migrtation function. The actual work is the transformation of instances of class A.Foo to class B.Foo; to be on the safe side one would have to copy over all attributes manually. If You want to try a fast and dirty solution, You could try to write the new class into the '__class__' attribute of the instance of the old class, making it an instance of the new class, but I do not know it this really works. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Patch disabling versions, was: Re: small summary and big plea
Hi Toby, I am sorry, but the patch to disable versions does not work for me (using Zope 2.6.1 / Python2.1.3), maybe because of trivial typo: === RCS file: /cvs-repository/Zope/lib/python/ZODB/ZApplication.py,v retrieving revision 1.13 diff -c -2 -r1.13 ZApplication.py *** lib/python/ZODB/ZApplication.py 8 Apr 2003 18:48:22 - 1.13 --- lib/python/ZODB/ZApplication.py 9 Jun 2003 22:58:43 - *** *** 42,49 def __bobo_traverse__(self, REQUEST=None, name=None): ! db, aname, version_support = self._stuff ! if version_support is not None and REQUEST is not None: ! version=REQUEST.get(version_support,'') ! else: version='' conn=db.open(version) --- 42,53 def __bobo_traverse__(self, REQUEST=None, name=None): ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev ! # ! # db, aname, version_support = self._stuff ! # if version_support is not None and REQUEST is not None: ! # version=REQUEST.get(version_support,'') ! # else: version='' ! version = '' conn=db.open(version) This seems to comment out db and aname, too. As one can see in the context of the diff, db is used in the very last line of the patch context. Zope gives me the NameError I would expect from the code when I send a request to the patched server. Dropping the comment from the line reading the _stuff seems to work for me: --- 42,53 def __bobo_traverse__(self, REQUEST=None, name=None): ! # Disable nasty insecure version support. Thanks to ! # Jamie Heilman and everyone one zope-dev ! # ! db, aname, version_support = self._stuff ! # if version_support is not None and REQUEST is not None: ! # version=REQUEST.get(version_support,'') ! # else: version='' ! version = '' conn=db.open(version) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] zeo2.0.2 and zope2.6.1 trouble
Just a wild guess: ERROR(200) Conflict Resolution Unexpected error Traceback (innermost last): File /usr/local/Zope-2.6.1-src/lib/python/ZODB/ConflictResolution.py, line 96, in tryToResolveConflict (Object: /usr/local/ZopeHome/var/Data.fs) SystemError: Failed to import class ClassicHTMLFile from module App.special_dtml This is logged by some bare except in the ZODB module, but it seems it has nothing to do with Your Data.fs. It seems the ZODB cannot import a class which should be there, however. Could You try to get a python shell for Your Zope installation and try the following commands (after fixing typos ;-): import Zope Zope.startup() from App.special_dtml import ClassicHTMLFile The last import normally should succeed, (it is in lib/python/App/special_dtml.py) but it seems in your case it failes for some reason. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Session Event Listeners
Beef a writes: Does anyone have any idea how to register session event listeners in Zope 2? [..] Check with the /temp_folder/session_data in your Zope, or create your own Transient Object Container, if there is no such object. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] support for low level HTTP Response logging?
Hi Romain, Yo, searching the zope site and googling yielded too many data and no info, so I might as well ask it here. We are very interested in finding out the exact HTTP Responses that the zope server pushes towards the client. So is there a low level hook for logging the http responses ? We want the exact response, complete with all header info etc. There is no explicit hook, but you might add Your logging code in Zope/lib/python/ZPublicher/HTTPResponse.py, for example in the 'write' method of the HTTPResponse, or by wrapping the 'self.stdout' in __init__ by something that also logs the output before writing to the passed 'stdout' stream. Of course this most probably will bring performance down (or even the complete Zope, if there is a simple typo in the hacked code ;-) I assume You only need this for testing. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] AIX
Hi Wolfgang, Hi, I run into the same problem that has been reported last year: Author:Jan Idzikowski Date: 04/24/2002 10:50 AM View: [Zope] Problems with AIX4 There never was an answer from anybody. I installed Python 2.1.3 and Zope-2.6.1 on AIX4.3.3 and I run into exactly the same scenario as Jan. ZServer starts up OK and I can login and bring up the control panel. I can also add folders. When I try to access /Examples or when I try to add the ZopeTutorial, Zope core dumps. When I run with the dbx debugger, I see that the runtime stack is busted. This looks like a hard one. Maybe You could first try to find the python level statement triggering the core dump via the pdb; e.g. see: http://www.zope.org/Members/michel/HowTos/TheDebuggerIsYourFriend Additionally You can narrow down the problem a little: does the problem appear, if Zope is running single threaded, too? (If it does, why does the 'testrunner.py' run? Maybe try to write a test visiting '/Examples'?) There have been some reports about problems with Zope and BSD, which are actually caused by some operating system stack overflow or such. Maybe a similar problem applies here, too? not very helpful, just a few thoughts. clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 and python compatibility
Tena Sakai writes: Greetings zope-dev folks, Please help me out. I have seen below via google search: Zope 2.5 + Python 2.1 -- Good Zope 2.6 + Python 2.1 -- Good Zope 2.7 + Python 2.1 -- Bad Zope 2.5 + Python 2.2 -- Bad Zope 2.6 + Python 2.2 -- Bad Zope 2.7 + Python 2.2 -- Good This article/note was from September, 2002. Can someone please comment if the data above is still valid? The information about the required python version should be in the README.txt file in the root directory of the Zope installation. If You check this file You will find that nothing had changed since September 2002. Cheers, Clemens ___ 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] Bug in ExternalMethods?
Hi Tim,
Here's a small demonstration of the bug:
--test.py--
def test(self, a_string, an_int, a_named_arg=1):
bug provoking?
template = a_string = %s; type(a_string) - %s\n
an_int = %s; type(an_int) - %s\n
a_named_arg = %s; type(a_named_arg) - %s
return template % (a_string, type(a_string), an_int, type(an_int),
a_named_arg, type(a_named_arg))
External methods need no self (and normally should have no self) as
first parameter, as they are not methods of some objects, I thought.
But Zope seems to do some magic here.
--Script (Python)--
return container.test('tim', 10, a_named_arg=(1,1))
return container.test('tim', 10, (1,1))
Indeed the first call should be illegal, as one passes only two
non-keyword arguments, but the function has three arguments without
default values. If I try to call the function from the python
command line in an equivalent way as done here by the script, I get an
TypeError: test() takes at least 3 non-keyword arguments (2 given).
But Zope seems to mangle in the container/context into the self argument,
if the following two conditions hold:
1. the first argument is named self.
(If the first argument is named foo, it does not work.)
2. there are to less arguments to make a normal function call
Condition 2. is true for the first call, but not for the second one.
Here enough arguments are provided to make a plaing function call
with the arguments:
self='tim', a_string=10, an_int=(1,1), a_named_arg=(1,1),
as defined by the caller or the default values.
Thus I guess it is not a bug, but a feature. There is actually an
example for this usage in the Zope Book (with the image thumbnails), but
at least I failed to recognise the magic self mumble.
Cheers,
Clemens
___
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] MailHost from 2.5.1 does not work in 2.6.0
... moving discussion from [EMAIL PROTECTED] to [EMAIL PROTECTED] Actually the topic has been that the smtp_port attribute of a MailHost has changed type from string in 2.5.1 to int in 2.6.0 I guessed a little hint about this incompatibility in the release notes would have been nice, but I can find nothing in this regard. I don't think anybody really was aware of it... :-/ It has to be fixed to 2.6.1 of course. The question is: Should the fix be to cast the smtp_port into an int every use (simple, functional, safe, ugly) or something else? Personally I guess it would be enough if there would be a notification that one should update the MailHost instances after upgrading. It is really easy; push the save button of the Edit tab fixes the issue without ado. That's actually very easy, and could be simulated by some script if one has more than N MailHost instances in one Zope instance (where N depends ones patience when clicking through the ZMI ;-) OTOH, there is exactly one place, where the smtp_host atrribute is used; lib/python/Products/MailHost/MailHost.py, line 214ff: security.declarePrivate( '_send' ) def _send( self, mfrom, mto, messageText ): Send the message smtpserver = SMTP( self.smtp_host, self.smtp_port ) # -- here smtpserver.sendmail( mfrom, mto, messageText ) smtpserver.quit() Thus if one does not trust people to read release notes, one could pragmatically add the int(...) cast here to avoid traffic on [EMAIL PROTECTED], though the cast is superfluous most of the time. [...] I checked some history. Up to 2.4 it was stored as an integer. For some reason it was changed between the final 2.5 beta and 2.5 release to be stored as a string, and then cast into an integer each time it was used. I don't know the rationale behind this change. [...] Well, if the change in 2.6.0 is actually a change _back_ to an old type, and nobody has complained about the change in 2.5, then it is maybe an unlucky accident Jan Ulrich Hasecke and me have created MailHost in 2.5.1, and everybody else will simply skip over this without notice. In this case my reply is too long already ;-) cheers, clemens ___ 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] Security problems importing from python package.
At Thu, 21 Nov 2002 12:16:09 +, Chris Withers wrote:
I'm trying to get stripogram working from Script(Pythons). I thought I had it,
but it appears I don't.
I added the following in the __init__.py of the stripogram package:
try:
from AccessControl import ModuleSecurityInfo,allow_module
except ImportError:
# no Zope around
raise
else:
allow_module('stripogram')
ModuleSecurityInfo('stripogram').declareObjectPublic()
ModuleSecurityInfo('stripogram').declarePublic('html2text', 'html2safehtml')
This issue is most probably resolved somewhere in between, but I can
not find any trace of this at [EMAIL PROTECTED] nor [EMAIL PROTECTED], thus I
drop in my 2 cents here.
I did just now run into a similar problem, and may offer the following
explanation after some debugging:
It seems the 'allow_module', etc, gets not executed by Zope in advance,
except if this is the __init__.py of a 'Product', or this module is
imported by some core module or product. This is quite standard python
behaviour; the module is not initialized before import, and Zope does
some extra work to initialize all products on startup.
If one tries to import the code from a python script, the security
machinery first check, if the module has some security info, and imports
it afterwards, if the info is found. But as the module is not imported
anyway, it is not initialized, and has not such info and thus will not
be allowed for import.
It seems there is some chicken and egg problem here, or I have missed
something completely.
The workaround is to insert a dummy 'import stripogram' in some
product, which triggers the security info creation -- or make the little
helper scripts a product of its own.
I don't think either the allow_module or the declareObjectPublic() should be
necessary. However, the declareObjectPublic at least made this test pass:
from Products.PythonScripts.PythonScript import PythonScript
theScript = PythonScript('test')
theScript.ZBindings_edit({})
theScript.write(from stripogram import html2text\nreturn
html2text('ihello/i'))
theScript._makeFunction()
self.assertEqual(theScript(),'hello')
This works, as Your test code imports something via file system (no
access restriction) from module stripogram first and then creates the
test script, which finds the module info on import as the module is
intialized yet.
But even adding the 'allow_module' won't let the following Script (Python)
created through the ZMI work:
from stripogram import html2text
The error I get is:
Error Type: ImportError
Error Value: import of stripogram is unauthorized
In this case the module has not been initialized yet, and the TTW
access is the first import, which failes due to the security
restrictions problem mentioned above.
Hope this helps; and hope someone can point me out I am wrong on the
chicken and egg problem of 'non-Product' module import.
Cheers,
Clemens
___
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] strange overflowerror long int too large to convert
Hi Tobias, Hi, we have a Zope-based (v2.5.0) editorial system running on a server of our customer's; it uses a ZUserFolder to store eMail addresses of the top-level users. Last week, an error turned up whenever the system tried to automatically send a notification eMail, which said: Error Type: OverflowError Error Value: long int too large to convert Poking around, I found that the error occurred as well when I tried to view the ZUserFolder instance in the root directory. Here is the traceback: Traceback (innermost last): [snip some traceback parts] (Object: /opt/zope/var/Data.fs) File /data/opt/Zope-2.5.0-linux2-x86/lib/python/ZODB/FileStorage.py, line 1902, in _loadBack OverflowError: (see above) (Zope 2.5.0 (binary release, python 2.1, linux2-x86), python 2.1.2, linux2) Since I can't find any relation to something we did: 1. Is this error known to anyone, possibly related to a known bug of Zope 2.5.0? 2. Is it possible that the usage of ZClasses is the reason for the problem, and that ZClasses tend to go berserk after a while? (our product contains nested ZClasses, which is not how we'd do it today, but how we did it... the user class used by ZUserFolder is not a nested one, though) 3. Can anyone give me a hint where to search for the bug? Hm, maybe looking at the source code? :-} def _loadBack(file, oid, back): seek=file.seek read=file.read while 1: old=U64(back) if not old: raise KeyError, oid seek(old) -- this seems to be line 1902 h=read(42) doid,serial,prev,tloc,vlen,plen = unpack(8s8s8s8sH8s, h) if vlen: seek(vlen+16,1) if plen != z64: return read(U64(plen)), serial back=read(8) # We got a back pointer! Maybe You ZODB has grown too big, i.e. over the 2GB limit, and python is not configured for having large file system support ... this should be in the release notes, but I cannot find it there ... By the way, You could try: utilities/ZODBTools/fstest.py to check, if Your ZODB is corrupted for some reason. ___ 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 )
