[Zope-CMF] Re: Problem with STX rendering
Charlie Clark wrote: [..] Sorry, but I can't see any relation: my post is solely related to content in the ZODB. Anyway doesn't Silva do this (work extremely well with external files) already? Sorry that I've been unclear as to what I meant. The point is not file system versus ZODB here but to provide an extensible framework to support format conversions (whether that's on import or export, view or save, etc) when and wherever needed. Basically, it is about redoing Plone/Archetypes' transformation tool, just better ;-) Having such a utility at hand then should allow to easily configure what formats to support in which context where your proposal (to add ReST support to the Document type) would be just one specific application. Raphael Charlie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Problem with STX rendering
Am 11.05.2007 um 18:31 schrieb Raphael Ritz: Just want to through this in here: Hanno is going to spend his GSoC project this year on reworking the transformation story for Plone http://code.google.com/soc/plone/appinfo.html?csaid=37C0499E14F646DC Maybe we give Hanno some pointers on what to consider as applications here ;-) Sorry, but I can't see any relation: my post is solely related to content in the ZODB. Anyway doesn't Silva do this (work extremely well with external files) already? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Problem with STX rendering
Tres Seaver wrote: [..] 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. Just want to through this in here: Hanno is going to spend his GSoC project this year on reworking the transformation story for Plone http://code.google.com/soc/plone/appinfo.html?csaid=37C0499E14F646DC Maybe we give Hanno some pointers on what to consider as applications here ;-) Raphael Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRI1d+gerLs4ltQ4RAvDmAJ9O6cIuYqKtmzgN5HpxkctOoO88qgCfc29s 94p20FM36hob+SHq48+YhiI= =rS7Y -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Problem with STX rendering
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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Problem with STX rendering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charlie Clark wrote: > Am 11.05.2007 um 01:09 schrieb Alexander Limi: > >> >> On Thu, 10 May 2007 07:28:49 -0700, Charlie Clark >> <[EMAIL PROTECTED]> wrote: >> >>> Anyway before I submit a follow-up to the bug is there any CMF >>> setting I can use to avoid this problem? >> It's a known issue with STX. > > Thanks, does that mean anything's being done about it? I would have > thought Plone users would be suffering the most with it. > > I spent some time looking at the underlying code yesterday and can > see what's causing the problem. If I take my own medicine the STX > code should be fixed. > > STLetters simply makes use of string.letters and string.digits which > are then thrown into various re's > > expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, > strongem_punc)) > > This will work with non-ascii only if the encoding for string.letters > and the text to be compared is the same which, certainly on my > machine is not the case, but can be easily fixed. > > letters = string.letters.decode(locale.getlocale()[1].encode > (WHATEVERCMFISPUSHING) 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. > 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. > 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. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRI1d+gerLs4ltQ4RAvDmAJ9O6cIuYqKtmzgN5HpxkctOoO88qgCfc29s 94p20FM36hob+SHq48+YhiI= =rS7Y -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Problem with STX rendering
Am 11.05.2007 um 01:09 schrieb Alexander Limi: On Thu, 10 May 2007 07:28:49 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: Anyway before I submit a follow-up to the bug is there any CMF setting I can use to avoid this problem? It's a known issue with STX. Thanks, does that mean anything's being done about it? I would have thought Plone users would be suffering the most with it. I spent some time looking at the underlying code yesterday and can see what's causing the problem. If I take my own medicine the STX code should be fixed. STLetters simply makes use of string.letters and string.digits which are then thrown into various re's expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc)) This will work with non-ascii only if the encoding for string.letters and the text to be compared is the same which, certainly on my machine is not the case, but can be easily fixed. letters = string.letters.decode(locale.getlocale()[1].encode (WHATEVERCMFISPUSHING) 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. 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? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Problem with STX rendering
On Thu, 10 May 2007 07:28:49 -0700, Charlie Clark <[EMAIL PROTECTED]> wrote: Anyway before I submit a follow-up to the bug is there any CMF setting I can use to avoid this problem? It's a known issue with STX. -- Alexander Limi · http://limi.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
