[Zope-CMF] Re: Problem with STX rendering

[Charlie Clark]

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
>> punctuation
>>
>> 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 Document.py 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?

Charlie

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üsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226