Am 11.05.2007 um 17:35 schrieb Tres Seaver:
It's worse, in that you have to re-encode to the charset being used by
*that* STX document, which there is no good algorithmic way to
after the fact. Only the HTTP Request which produced the document (in
the case of a ZODB-based thing like CMFDefault.Document) has enough
information to establish the encoding being used.
So, you should pull it out of the REQUEST and pass it through? I
guess that's doable but I know as a fact that one of my servers
doesn't support locale.setlocale() it doesn't actually help me.
I thought that the default_zpublisher_encoding would do but that's
wrong. Assuming it's possible to get the value from Zope surely this
would be a relatively painless fix?
It might be an idea would be to hook into the ReST encoding
directives that are mysteriously included in /etc/zope.conf
An alternative would be to coerce the use of unicode and simply
compare against that:
re.compile(r'\*\*([\s\w]+?)\*\*', re.U) #extended as necessary for
The advantage of this is that it would be entirely independent of
locale but this would take more work on STX which seems to choke if
If converted during the upload, you solve the "which encoding is this
document in?" problem.
I think this is how ReST does it. It will choke on non-ascii if those
encodings aren't set and if they are then Zope should be taking care
of the transcoding - wouldn't it be nice to have a transcode
(input_encoding, output_encoding) in Python!
Going back briefly to ReST: if Zope seems ready to support this out
of the box, wouldn't it useful to support ReST in
CMFDefault.Document? Or is the dependency on docutils too precarious?
It could be added gracefully to the edit form if import
reStructuredText succeeded. Or is this yet another case of me being
behind the loop again?
That might be simpler than the change I have wanted to make, which
register named utilities for a new utility interface, and then
the drop-down for "Format" with all registered utilities.
er, is this an answer to the question should we add support for ReST?
Or is it picking up the idea of using the encoding directives in
zope.conf? If the latter, then not only would it be simpler, it would
also "all be in one place".
Adding support for ReST turns out to be really easy: only three
methods (_edit, CookedBody and setFormat) are affected and the
associated edit templates (document_edit_template,
newsitem_edit_template) and anything derived. The only thing I'm not
sure is letting it fail gracefully in case docutils and, therefore,
ReST isn't available. How can I set a constant in Document.py say
REST_AVAILABLE which I can check for in the doc templates using
Will check my changes with 2.1 later and, now that I've got svn
installed, I'll try and make a diff (also for my getNextEvent()
method for the Calendar) which works fine except for the fact it
seems to need a restart to be noticed! As this would be new stuff, I
assume it goes into a putative CMF 2.2?
PS. A big thanks to everyone for the CMF. The new eGenix website is
built using the CMF and we're very happy with it, ie. I managed to
convince Marc-André to use it in the first place and he's been happy
by what we've been able to do with it.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests