[Zope-dev] Testing zope 3 utilities from zope 2
hi, I'm writing a unit test for GS exportimport of the Plone 3.0 plone.app.viewletmanager product. the exportimport handler configures a storage which is a Zope 3 utility. As I want to include support for same node attributes than the skins tool exportimport handler, I took inspiration from the tests in CMFCore/exportimport/tests. My problem is that the utility keeps its settings in all test methods of a test case. Therefore, I can not properly test the exportimport steps. I tried to call unregisterUtility() in the tearDown() method of the test class but that doesn't change anything. Any suggesion on how to solve this particular problem? Current state of the code is in https://svn.plone.org/svn/plone/plone.app.viewletmanager/branches/6649-default-order-support/tests/test_exportimport.py the test_z_means_last() test method output make it obvious, the utility keeps its settings. Thank you in advance, David ___ 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] Re: Testing zope 3 utilities from zope 2
I've been looking for a solution during hours before posting the question, and of course I found the solution right after posting it. I needed to use the setHooks() and setSite() from zope.app.component.hooks Sorry for the noise on the list, David David Convent wrote: hi, I'm writing a unit test for GS exportimport of the Plone 3.0 plone.app.viewletmanager product. the exportimport handler configures a storage which is a Zope 3 utility. As I want to include support for same node attributes than the skins tool exportimport handler, I took inspiration from the tests in CMFCore/exportimport/tests. My problem is that the utility keeps its settings in all test methods of a test case. Therefore, I can not properly test the exportimport steps. I tried to call unregisterUtility() in the tearDown() method of the test class but that doesn't change anything. Any suggesion on how to solve this particular problem? Current state of the code is in https://svn.plone.org/svn/plone/plone.app.viewletmanager/branches/6649-default-order-support/tests/test_exportimport.py the test_z_means_last() test method output make it obvious, the utility keeps its settings. Thank you in advance, David ___ 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] error trying to import smtplib (unauthorized)
Python scripts are run in a restricted environment, move your code to either an external method or a python zope product built on the filesystem Nicolas Georgakopoulos wrote: Trying to execute the following code from a python script from smtplib import SMTP from email.MIMEText import MIMEText I get a error: *Error Type: ImportError* *Error Value: import of SMTP from smtplib is unauthorized. You are not allowed to access 'SMTP' in this context * Why I can't access SMTP if I am a user manager with all the access enabled for managers in the current context ? ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) . ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] BTreeFolder doubleclick patch
Peter Bengtsson wrote: Shane (and the Zope list), I've patched your lovely BTreeFolder2 product (version 1.0.1) so that I can doubleclick on options in the dropdown instead of having to click the Edit button. This is using Javascript and if Javascript is disabled, nothing happens, it just goes back to what it was like before. I've attached two patch files that you can chose to include. Peter, I can't find the attached files. Maybe you forgot to attach them or the list has removed them before sending to everybody? PS. To install the patch, this works for me: $ cd zope/Products/BTreeFolder2/ $patch -p1 BTreeFolder2.py.patch ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Code
Hi Jean, if you want to use python code in an unrestricted environement, you should use ExternalMethods or write Python based Zope product on your filesystem. External Methods are better choice to beging with. You can learn more about External Methods from the Zope Book. Regards, [EMAIL PROTECTED] wrote: Hello the list, I want to use all the possibilities of python in my ZOPE local server. Do you know which file can I modify to enable this? Where must I contact to know that? Best regards. Jean Tinguely. -- David ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Folder Listing as a Plone Portlet Mini-HOWTO (draft)
Matthew X. Economou wrote: http://web.irtnog.org/Members/xenophon/plone/portlet-folder-contents This folder listing portlet displays the title of the folder, its description, and a list of each item in the folder. Mousing over each link pops up its description in browsers that understand the title anchor (A) tag attribute. Your comments and suggestions are greatly appreciated! Plone now uses catalog queries to build folder listings, it avoids waking up all objects and slow down the server response. Consider using it, your portlet as it is written now can slow down the browsing of a folder containing a large amount of objects. HTH, Best wishes, Matthew ___ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Re: [Archetypes-devel] Unicode in Zope 2 (ZMI, Archetypes, Plone, Formulator)
Hi Bjorn, I always believed that unicode and utf-8 were same encoding, but reading you let me think i was wrong. Can you tell me what the difference is between unicode and utf-8 ? Bjorn Stabell wrote: While we're all waiting for Zope 3 and Plone 3, I'd like to know what the standard practice way of using Unicode with Zope 2. In particular, we'd like to store all text as Unicode in the ZODB, and have Zope do the encoding/decoding as automatically and transparently as possible. We've been using Zope 2's ZPublisher to do this encoding/decoding for over 2 years, and it's working fine. We just have to ensure that we set the appropriate encoding in a HTTP Content-type header, and that we add :utext/ustring:ENCODING to HTML form field names. Regardless of what you may have heard, THIS WORKS FINE! We also store Unicode, not UTF-8 (or other encodings), strings in the ZODB. The problem we're running into are with other components, basically making our Unicode-with-Zope experience, shall we say, less than ecstatic (To put it this way, I seem to lose hair much faster when dealing with Unicode problems :) I'm wondering why components/products aren't all relying on the ZPublisher for Unicode encoding/decoding? Is there another standard way? Here is a summary of what we've found: ZMI * gets charset from manage_page_charset encoding * relies on ZPublisher for encoding (but doesn't do decoding, see below) * in PropertyManager you can add ustrings, but since it doesn't add :ENCODING to the field names, you get a Unicode error when trying to save since it tries to decode the text assuming ASCII (big problem) * DTML Methods/Documents: doesn't support Unicode (annoying) * can't use Unicode id's (not a big problem) Archetypes: * gets charset from portal_url.getCharset() or portal_properties.site_properties.default_charset * doesn't rely on ZPublisher, does its own encoding/decoding * returns encoded strings, not Unicode strings, to Zope apps, leading to problems such as: - SearcableText() encodes, and as such can't be used with Unicode-aware ZCatalogs - transform() encodes (and because of that SearchableText() sometimes decodes/encodes 2 times instead of 0 times) - get()ing field values will encode them, so if you want Unicode, you have to decode yourself (adding both unnecessary overhead for data access, and unnecessary dependency on the global variable for the charset) Plone: * no special Unicode support for HTML forms; relies on Archetypes Formulator: * gets charset from manage_page_charset (same as ZMI), but can be overridden * stores field values as encoded text (not Unicode), but lets you specify which encoding to use (confusingly calls this unicode mode) * messages are stored as UTF-8 (hardcoded) I suggest this way of dealing with Unicode right now in Zope 2: (1) Let ZPublisher do the encoding/decoding of form input and HTML output: a. Always set a character encoding in a HTTP Content-type request b. Always append :ustring/utext/ulines/utokens:ENCODING to field names of fields that support Unicode (we may need some library code to make this easier) (2) Store Unicode strings directly in the ZODB. The ZODB is perfectly capable of storing strings in Python's internal Unicode format; no need to encode the text to UTF-8 or some other encoding. (3) Encode/decode yourself when reading from/ writing to other external data sources such as files and other databases. Do it just before you write, or just after you read, so that as much code as possible can be encoding-agnostic. Keep the encoding/decoding as close to the source data as possible. The best way to do it is (in most cases) to specify the encoding on the IO stream, and let Python do the encoding/decoding for you transparently. If possible, get the encoding from the external data source (e.g., the file) instead of relying on a magical global variable. If you have to rely on a global variable, let it be manage_page_charset. (4) [This is really just advice...] Resist patching your code to work with components that doesn't deal with Unicode. Others are likely having the same problem, so to avoid ending up with lots of ugly patches (that are the source of mysterious Unicode problems), fix the problem at its source: the other component. It's really not that difficult to fix (if we agree on how it should be fixed ;) None of the above components handles Unicode in this way, but it seems to be how the Unicode support in Zope 2 was meant to be used. Let me know if there is another better way, but please do let me know... I think we need to resolve this once and for all or I know some people that'll just go mad (or bald, or both) :) I'll be willing to contribute patches, but since this applies to so many products, it would be good to get some consensus first. At the very least, can we create a Standard Unicode Practices page? Bye, -- David Convent ___ Zope-Dev maillist - [EMAIL PROTECTED
