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 determine
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
fed unicode.

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 is to register named utilities for a new utility interface, and then populate
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 say REST_AVAILABLE which I can check for in the doc templates using tal:condition?

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.
Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to