Re: [Zope] utf-8 problem in Zope when using Localizer
--On 24. August 2007 08:32:17 +0200 Patrick Ulmer <[EMAIL PROTECTED]> wrote: Hi, because nobody in der Localizer-Mailings list react and I thinks it could be a common problem with utf-8 in zope, I ask my question here also. I use Localizer 1.2.1 and I try out some things and all looks great. After testing Localizer my next plan was to switch from encoding ISO-8859-15 to utf-8 in Zope 2.10.3 but run into Problems when inserting text through a MessageCatalog (object of Localizer). Here is what I do in Zope: 1. I add "default-zpublisher-encoding utf-8" to my zope.conf and restart zope. 2. In ZMI I add the property "management_page_charset" and set it to "utf-8" 3. I add a new "DTML Document" and start editing. I check the encoding in my Browser and it switched to "unicode (utf-8)". Looks good. 4. I insert html-code and some russian chars for testing ...russian chars... After Saving all looks great in ZMI and also in my webbrowser. 5. Now I add one line to use a MessageCatalog: After that, all of my utf-8-chars are broken in my webbrowser. I check browser-encoding and it is still utf-8. In ZMI my "DTML Document" looks good. This line must switch something in the output-encoding in the internal page-render (I don't know, how to better explain it). Is this an error in Localizer or in Zope or have I overlook a fault? The http-equiv tag means not much to browser. Try setting the content-type including the charset within the HTTP response (REQUEST.RESPONSE.setHeader(...)). -aj pgpyJCX7p3dYG.pgp Description: PGP signature ___ 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] utf-8 problem in Zope when using Localizer
Hi, because nobody in der Localizer-Mailings list react and I thinks it could be a common problem with utf-8 in zope, I ask my question here also. I use Localizer 1.2.1 and I try out some things and all looks great. After testing Localizer my next plan was to switch from encoding ISO-8859-15 to utf-8 in Zope 2.10.3 but run into Problems when inserting text through a MessageCatalog (object of Localizer). Here is what I do in Zope: 1. I add "default-zpublisher-encoding utf-8" to my zope.conf and restart zope. 2. In ZMI I add the property "management_page_charset" and set it to "utf-8" 3. I add a new "DTML Document" and start editing. I check the encoding in my Browser and it switched to "unicode (utf-8)". Looks good. 4. I insert html-code and some russian chars for testing ...russian chars... After Saving all looks great in ZMI and also in my webbrowser. 5. Now I add one line to use a MessageCatalog: After that, all of my utf-8-chars are broken in my webbrowser. I check browser-encoding and it is still utf-8. In ZMI my "DTML Document" looks good. This line must switch something in the output-encoding in the internal page-render (I don't know, how to better explain it). Is this an error in Localizer or in Zope or have I overlook a fault? Thanks Patrick ___ 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] New set of z3c.form* releases!
Hi everyone, in the past month more project-related work, user feedback/requests and Javascript work has driven the development of the z3c.form framework. There are many new exciting features. There were also some small refactoring changes, which might require your CSS and tests to be adjusted. Please read the changes section below carefully! As always, the demos can be run using: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.4.0 formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout -N $ ./bin/demo fg Thanks to Roger, Windows users should be able to run the demos this way now as well! Visually, not much has happened; there are no new demos. However, just wait until the next round of z3c.formjs* releases! Changes --- - Feature: An event handler for ``ActionErrorOccurred`` events is registered to merge the action error into the form's error collectors, such as ``form.widgets.errors`` and ``form.widgets['name'].error`` (if applicable). It also sets the status of the form. (Thanks to Herman Himmelbauer, who requested the feature, for providing use cases.) - Feature: Action can now raise ``ActionExecutionError`` exceptions that will be handled by the framework. These errors wrap the original error. If an error is specific to a widget, then the widget name is passed to a special ``WidgetActionExecutionError`` error. (Thanks to Herman Himmelbauer, who requested the feature, for providing use cases.) - Feature: After an action handler has been executed, an action executed event is sent to the system. If the execution was successful, the event is ``ActionSuccessfull`` event is sent. If an action execution error was raised, the ``ActionErrorOccurred`` event is raised. (Thanks to Herman Himmelbauer, who requested the feature, for providing use cases.) - Feature: The ``applyChanges()`` function now returns a dictionary of changes (grouped by interface) instead of a boolean. This allows us to generate a more detailed object-modified event. If no changes are applied, an empty dictionary is returned. The new behavior is compatible with the old one, so no changes to your code are required. (Thanks to Darryl Cousins for the request and implementation.) - Feature: A new ``InvalidErrorViewSnippet`` class provides an error view snippet for ``zope.interface.Invalid`` exceptions, which are frequently used for invariants. - Feature: When a widget is required, HTML-based widgets now declare a "required" class. - Feature: The validation data wrapper now knows about the context of the validation, which provides a hook for invariants to access the environment. - Feature: The BoolTerms term tokens are now cosntants and stay the same, even if the label has changed. The choice for the token is "true" and "false". By default it used to be "yes" and "no", so you probably have to change some unit tests. Functional tests are still okay, because you select by term title. - Feature: BoolTerms now expose the labels for the true and false values to the class. This makes it a matter of doing trivial sub-classing to change the labels for boolean terms. - Feature: Exposed several attributes of the widget manager to the form for convenience. The attributes are: mode, ignoreContext, ignoreRequest, ignoreReadonly. - Feature: Provide more user-friendly error messages for number formatting. - Refactoring: The widget specific class name was in camel-case. A converntion that later developed uses always dash-based naming of HTML/CSS related variables. So for example, the class name "textWidget" is now "text-widget". This change will most likely require some changes to your CSS declarations! - Documentation: The text of ``field.txt`` has been reviewed linguistically. - Documentation: While reviewing the ``form.txt`` with some people, several unclear and incomplete statements were discovered and fixed. - Bug (IE): In Internet Explorer, when a label for a radio input field is only placed around the text describing the choice, then only the text is surrounded by a dashed box. IE users reported this to be confusing, thus we now place the label around the text and the input element so that both are surrounded by the dashed border. In Firefox and KHTML (Safari) only the radio button is surrounded all the time. - Bug: When extracting and validating data in the widget manager, invariant errors were not converted to error view snippets. - Bug: When error view snippets were not widget-specific -- in other words, the ``widget`` attribute was ``None`` -- rendering the template would fail. Enjoy! ___ 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] Global Variable In PT
--On 23. August 2007 13:47:15 -0400 [EMAIL PROTECTED] wrote: Hi: I have this code (editing out the extraneous) at the beginning of a page: After calling some other variables (specifically rotating through a changing ¨item¨ (for item in items...)), I try and change newRow: Using 'global' is basically bad-style. It is even more bad-style to modify global variables in ZPT. Rethink your problem. If necessary move the related code into a Python script. -aj pgpZ69HCeLXYf.pgp Description: PGP signature ___ 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] Global Variable In PT
Hi: I have this code (editing out the extraneous) at the beginning of a page: After calling some other variables (specifically rotating through a changing ¨item¨ (for item in items...)), I try and change newRow: Then I try and call newRow: But it gives me the original value. Now, if I edit the page like this: it gives me a different value (the one I expect and want). Obviously, my ¨global¨ definition isn´t going global. What can I do to make it global; that is, call it outside of the span tag? TIA, Tony Email and AIM finally together. You've gotta check out free AOL Mail! - http://mail.aol.com ___ 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 )
