[Zope-CMF] Re: Problem with STX rendering
charlie at begeistert.org
Fri May 11 12:01:51 EDT 2007
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
>> 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
> 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.
More information about the Zope-CMF