Re: [Zope-dev] ZTK 2.0: Deprecate zope.sequencesort
Hi Tres, Am 28.02.2013, 21:04 Uhr, schrieb Tres Seaver : The main export of the package is the 'sort' function, which takes a sequence, per-column sort specs (key/attr name, sort function, direction), and optional extra data (e.g., the DTML namespace) and a flag indicating whether to use key or attribute lookup. The 'SortBy' class is really just an implementation detail of that API. I guess the right way to port the package is to implement a sort API. I have ported it to Python 3.2 and 3.3 and released a 4.0.0 version. Thanks for the port. I guess the question is still whether it should still be in ZTK - providing DTML as an example suggests that this really is a Zope only library. Do you see use for it outside the Zope context? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Error suitable python version
Hi Peppe, although I don't think your issue is related to the development of Zope, if you don't keep this on mailing list no one else will see any possible issues- Am 07.12.2012, 19:25 Uhr, schrieb peppe scuglia : Hi When i try to install with Bin/easy_install -i http://download.zope.org/Zope2.2.13.19 Zope2 Why on earth are you do want to do that? bin/pip install Zope2 works fine. Note, unless you have a clear idea of exactly what you want to do it's unusual to install Zope directly like that and Zope is a little too big just to try out. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Error suitable python version
Am 06.12.2012, 17:14 Uhr, schrieb peppe scuglia : What version of zope you recommends for python 2.6.6? Thanks again for your disponibility The current version of Zope is 2.13.19 Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Error suitable python version
Hi Peppe, Am 06.12.2012, 16:58 Uhr, schrieb peppe scuglia : Hi I use python 2.6.6 but i dont know why there is an error when i try to install zope 2.8.2 or zope 3.4.0 using Linux. It find the interpreter of python 2.6.6 in usr/bin/python , but when i make .configure --with-python /usr/bin/python , there is an error "no suitable python version found. You should install Python version 2.4.3 before continuing. Versions 2.4.7 etc... I read that this version of python 2.6.6 run on zope 2.8.2 or 3.4.0 Please help me!! What have i do?? You cannot use Python 2.6 with Zope < 2.12. Zope 2.8 is no longer supported. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 18:21 Uhr, schrieb Charlie Clark
:
Let me explain: in pdb I have access to request.form which is where I
can see the difference. With Sentry I can only see the raw body of the
request. I may simply have not understood well enough how to use it to
inspect what's happening.
I raise an exception in both cases in the forms' validate method.
Do you see this until you extract it first from the request object?
You are not having one form saying fieldname:string and the other just
fieldname?
No, they are all zope.formlib/zope.schema fields so there is no
additional marshalling.
I have finally tracked down the problem: I seem to have been bitten by a
change in zope.formlib 4.1.
There are two solutions: either extend a form's update method with the
something like the following:
def update(self):
from Products.Five.browser.decode import processInputs
from ZPublisher import HTTPRequest
# XXX: if we don't set default_encoding explicitly, main_template
might
# set a different charset
self.request.RESPONSE.setHeader('Content-Type',
'text/html; charset=%s' % HTTPRequest.default_encoding)
# BBB: for Zope < 2.14
if not getattr(self.request, 'postProcessInputs', False):
processInputs(self.request, [HTTPRequest.default_encoding])
super(_EditFormMixin, self).update()
Or, more simply, base forms on those provided by five.formlib.formbase
Thanks to yuppie for fixing this in the CMF.
I can confirm that this also works with Internet Explorer.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fwd: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 09:37 Uhr, schrieb Adam GROSZER : Opera? which version and OS and whatnot? 12.12 on Mac OS 10.7.5 As originally noted, I don't have the problem in the same browser with an extremely similar form on a different site. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fwd: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
Am 30.11.2012, 08:29 Uhr, schrieb Adam GROSZER : I think I had the same. My hunch was IE, but had no repro. If you *have* a repro, you could log the *whole* raw request input and investigate what's the difference. Hi Adam, this is different from the usual IE & Safari shenanigans which were related to the accept_charset not being sent and Zope making a bad guess. I can reproduce the error without difficulty in Opera. I'm going to try a new instance of the site and see how that behaves. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Fwd: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib
I'm forwarding this from the CMF list as I'm stumped. I worked my way up the debug stack but couldn't find what was causing one Zope instance to decode to unicode and the other to leave content as utf-8 (or maybe it's the other way round?). Both instances on the same machine. Any ideas? Charlie --- Weitergeleitete Nachricht --- Von: "Charlie Clark" An: zope-...@zope.org Kopie: Betreff: Re: [Zope-CMF] Weird UnicodeDecodeError with zope.formlib Datum: Thu, 29 Nov 2012 11:52:13 +0100 Am 29.11.2012, 09:43 Uhr, schrieb Charlie Clark : No. I guess I'll have to look more closely at the wigdets data. As I said a different site on the same machine doesn't exhibit these problems so I should have a point of comparison. Definitely weird. From site 1: (Pdb) t = self.widgets['town'] (Pdb) t._getFormInput() u'D\xfcsseldorf' as expected but from site 2: (Pdb) t = self.widgets['town'] (Pdb) t._getFormInput() 'D\xc3\xbcsseldorf' Note the similarity of the field name as one of these forms started out as a copy of the other. Need to check what is causing this. I think I might have set a default encoding for Zope to UTF8 ostensibly to reduce IE / Safari errors. Oh, isn't this fun! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Small fix in Products.ZCTextIndex, how to go further?
Am 14.11.2012, 16:26 Uhr, schrieb Hanno Schlichting : Hi. The change looks ok. But I think you broke an optimization. IIRC the code compares the old and new values for the index, and skips the indexing step if they are the same. The typical item.reindexObject() call sents data for all indexes, even if just one or two them have changed. The optimization made sure to skip any extra work, if there wasn't really any change for the text index. Without that check, you end up updating and writing a bunch of internal data structures in the text index every time. Those lead to slower write performance and more conflict errors. Could you have another look, and see if you can preserve the optimization? Could we also have a clean up with a specific exception in the try: except: clause? I assume we're expecting an AttributeError? And move filter to a generator expression / list comprehension? I could say for Python 3 compatibility but that doesn't matter so much as there is no easy way for the isinstance(t, basestring) Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 Sprint Report [was: (no subject)]
Am 10.09.2012, 21:54 Uhr, schrieb Leonardo Rochael Almeida : The expectation is to be able to release a Zope4 alpha by the end of the year. Next sprint will be at the Plone Conference in Arnhem, focussing on WSGI and merging branches. Hi Leonardo, thank you very much for the report. It's nice to see that ideas for Zope's future are crystallising. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
Am 20.08.2012, 13:25 Uhr, schrieb Jim Fulton : FTR, in the case of svn.zope.org, it's ZC hardware and hosting with a lot of much appreciated help from Jens. My mistake, I thought that Foundation owned it's own hardware. I must have misinterpreted something. We're doing a pretty ok job (if you ignore a near catastrophe) in providing what is, by today's standards, a bare-bones service. User management is awkward. We lack any automated support for review, and a number of other services provides by github and bitbucket. svn.zope.org doesn't take much of my time most of the time, but it's still a potential (and occasional real) time suck for me that I'd love to jettison. This is a very good reason to examine the services of a commercial provider (independently of the discussion or what tools are required or desirable). Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
Am 20.08.2012, 12:50 Uhr, schrieb Robert Niederreiter : On 20.08.2012 12:39, Charlie Clark wrote: Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter : There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself. ah, the common cold defence: everyone has it so it must be good. no, just a manner of chance. and even if, git is not proprietary. Git is the tool and not the service. https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. This is pure speculation, or are you privy to board decisions at Github. see above, git is not proprietary. nobody is trapped inside github at all if nasty things happen. Changes to the T&C's that substantially affect this can happen at any time. lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github... This irrelevant in the context of ownership and copyright. you came up with concerns against VC's. So in which context was this meant then? Without wanting to start a diatribe against VC's: the key term was "beholden to". VC's are understandably interested in a quick and substantial return on their investment and will do whatever it takes to achieve that. They are not philanthropists and ownership is a key lever for them. This is a fundamentally different proposition to paying for a service from a company or setting up an organisation to do it yourself. There is no free lunch. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter : There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself. ah, the common cold defence: everyone has it so it must be good. https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. This is pure speculation, or are you privy to board decisions at Github. lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github... This irrelevant in the context of ownership and copyright. even the linux kernel guys seem to prefer the benefits of github. https://github.com/torvalds/linux Yes, promotional materials would have nothing to do with the commercial nature of the service. Not that I'm against a commercial service provider. still, all your concerns are reasonable, but the claimed implications should stay lifelike. I raised a specific objection: that the onus is on anyone with a Github account to demonstrate their code does not violate any patents in the case of a claim feels like a pretty real threat to me. Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider. Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro : Such as? As previously noted: the T&C's in particular the indemnification clause. Plus, the usual when dealing with an apparently free service provided by a company beholden to VC's. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Am 18.08.2012, 15:35 Uhr, schrieb Chris Withers : I'm not going to dignify this with a fuller response other than to say that Jean-Paul Smets' entire email is nothing but bullshit written to try and promote an inferior competing product. The issues of hosting and vcs were aired a few months ago and should be considered separately. The T&C's of any of the these products should be read carefully and I, for one, do not like the indemnification clause at Github. I would, therefore, agree with Jean-Paul in this respect. I agree with Jens, that new work should be considered as a fork. It currently feels very much cloak & dagger. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope trunk: browser views
Am 10.07.2012, 16:29 Uhr, schrieb yuppie : Hi! Zope 2 has customized implementations of the ``browser:view`` and ``browser:page`` directives. I tried to make that code more similar to zope.browserpage without breaking Zope 2 and CMF. I guess the biggest change I made was removing the Five version of BrowserView from the base classes. Please let me know if you have any questions or if I did break something. Hi Yuppie, I'm sure that's going to break any code that has from Products.Five import BrowserView in it. What should this be replaced by? And what changes in ZCML? Most of my code sits upon CMF so I hope I should be reasonably insulated through that. But the change is probably a good thing™ so thanks in advance. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Add zmi_views 'fix' also for zope.app packages?
Hi Uli, Am 29.05.2012, 13:44 Uhr, schrieb Uli Fouquet : Hi there, As Christopher Lozinski pointed out, there seem to be usecases where people want to use single zope.app packages without zope.app.zcmlfiles and the whole bunch of zope.app packages it pulls in. I think this is a non-usecase. zope.app is a namespace for the "app" part of Zope. If you want to use a part of this app then it's reasonable to assume that you want the rest: caveat developor! Would it make sense for these packages to also register ZMI related stuff only if some condition is met (say: zope.app.zcmlfiles is installed)? No, having apps trying to guess about their use as library code is a bad idea and should not be encouraged. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: zope.interface/branches/tseaver-no_2to3
Am 05.04.2012, 22:36 Uhr, schrieb Tres Seaver : Unless the community's consensus is against the branch, I plan to merge it to the zope.interface trunk by early next week. + many/lots! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 27.03.2012, 16:04 Uhr, schrieb Fred Drake : Transcoding on the fly? The page template generates Unicode; that's then encoded. Are you suggesting we shouldn't be using Unicode as the internal representation? Not at all, just harking back to the time when we didn't use unicode internally. In the CMF we still have to deal with that on occasion. Failure to do so would make it easy to get things wrong. Indeed. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 27.03.2012, 12:16 Uhr, schrieb Fred Drake : In other words... "the web" will continue to thrive on hacks and sniffing data to support users' expectations in spite of the data on "the web". I appreciate the motivation (it's not the users' fault the content provider can't get it right), it saddens me that there will no end of quirks-mode-like data interpretation. And that after this many years, we still can't get content-type and encodings straightened out. True but I think that the problem was largely of our own making in not coming up with "one, preferably only one" way of handling this. Re-reading Marius' post I was struck by the whole idea of the http-server transcoding the content on the fly. Now, I've never looked at this in detail but have any of the major webservers ever done that? Having struggled in the past with "weird" encoding errors limited to Safari and IE only, probably caused by me not handling the encode/decode chain properly in my code but still left staring unbelievingly at a long and confusing traceback and yearning for an easy to way "to do the right thing" which in my view should be the webserver trying to serve up UTF-8. I guess, that years ago we had to worry much more about encodings (latin-1, windows-1252, mac-roman, IBM code pages, and whatever unix was doing). I've been reading about http 2.0 coming up - is this going to improve the matter? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 25.02.2012, 00:18 Uhr, schrieb Marius Gedminas : The HTML spec requires that: "To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest): 1. An HTTP "charset" parameter in a "Content-Type" field. 2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset". 3. The charset attribute set on an element that designates an external resource." -- http://www.w3.org/TR/html4/charset.html#h-5.2.2 (Aside: The rationale for this ordering, IIRC, is that it allows HTTP servers to do on-the-fly charset conversion from one 8-bit charset to a different one, without having to parse HTML and modify the charset name in the declaration.) As a follow up to this it's worth noting that as from Opera 12 the practice will be: * BOM sniffing * http header * meta declaration In that order and inline with Webkit and IE: """ It is better to encode your Web pages in UTF-8, and serve them as such. In HTTP, the HTTP header has priority, then the meta name contained in HTML. Some Web pages have specific encoding. It happens often on the Web that the Web page encoding is different from the one specified in the file and/or the one specified in HTTP headers. It creates issues for users who receive unreadable characters on their screens. So the browsers have to fix the encoding on the fly. We had bug reports about Web sites sending BOM different from the HTTP header. We decided to make the BOM authoritative like webkit and IE, because there are more chances for it to be exact than the HTTP headers. """ http://my.opera.com/ODIN/blog/2012/03/26/whats-new-in-opera-development-snapshots-march-26-2012 Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New release for zope.schema
Am 22.03.2012, 15:27 Uhr, schrieb Jan-Carel Brand : Any ideas why this vocabulary doesn't provide it in Python 3? I think you have to use the @implements class decorator for Python 3. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Content Type Meta tag stripping in zope.pagetemplate
Am 24.02.2012, 09:47 Uhr, schrieb Miano Njoka : While it is not essential, it is necessary in some cases where the finished document will be read from disk or is used by other applications eg. Deliverance[http://packages.python.org/Deliverance/]. In fact w3c's HTML validator throws a warning that one should declare the character encoding in the document itself if it is missing. This is actually what the validator says: """ No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc. """ As ZPT produces XHTML the proper place for any encoding declaration is in the XML declaration, defaulting to UTF-8, which should throw a validation error if incorrect. Like much of the HTML standard the meta tags were never really thought through and, because invisible to the user, all too often copied mindlessly from one project to another: I have customers today with completely invalid and misleading meta tags of which they and the rest of the world is blissfully unware. And as a result browsers - the main consumers of the format were made fault tolerant - after all the user often had no idea what was causing the problem or how to rectify it. I have seen many examples of the server saying one think and the meta something else entirely. I think nearly all browsers believe what the server says over what's in the meta tag. According to MAMA, which was instrumental in developing HTML 5 based on what has actually been written, the charset was set in the http-headersover 99 % of the time. Unfortunately, it doesn't contain any stats on discrepancies between the http-header and the meta. http://dev.opera.com/articles/view/mama While there is apparently a possible security risk when not declaring the charset I think the Pythonic principle of "there should be preferably one obvious way to do something" should apply when within Zope trying to decide the charset of a file and that should be well documented. I'd suggest keeping the stripping but implementing a more rigorous approach such as you suggest. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, ... lots cut ... I like the _populateIndexes() method. Having a single pass without a signifying parameter makes it easier to understand. Am 06.02.2012, 10:12 Uhr, schrieb Jan-Carel Brand : A vocabulary must minimally be able to determine whether it contains a value, to create a term object for a value, and to return a query interface (or None) to find items in itself. So it looks like someone thinks that any vocabulary must be able to create a term object. Thoughts on that? Yes: I think it's much more important to define what kind of terms are expected. Apart from local utilities I've never come across the need to add terms individually and even then term generation is outside the scope of the vocabulary as you already have a term factory. Validating terms seems more important so I guess and __setitem__() method which imposes the same checks as you run in _populateIndexes() might be worthwhile to stop the index being fouled up by application code. I think I'm now finished and have implemented everybody's suggestions and improvements. The TreeVocabulary now has a terms_factory attribute which is an OrderedDict by default and which can be overridden in a subclass to an alternative datastructure. It also implements IEnumerableMapping. All the TreeVocabulary methods are covered by tests and I tested with Python 2.6 and Python 2.7. If there aren't any more objections, I'd like to now merge with trunk. I think it's okay to go ahead and merge. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
Am 01.02.2012, 15:40 Uhr, schrieb Alexandre Garel : All I see here is usability not religion Which is pretty much what Jens said originally. To me, much of the argument seems to be trying to solve a different problem: getting more people involved in contributing to Zope or at least maintaining important packages. While this is a laudable goal I think it is has little to do with the tools involved, something that is becomingly increasingly irrelevant as more and more third-party packages are used in Zope projects; something which Zope did a great deal to encourage. Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. On hosting: personally, it does matter to me a great deal where the little code I write is hosted. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PyConUS sprint on Zope 4
Am 29.01.2012, 22:29 Uhr, schrieb Leonardo Rochael Almeida : Hi, Anyone going to this PyConUS who would like to sprint on Zope4? Topics of particular interest to me include security (as I explained in a previous e-mail) and the new ZMI. Hiya, I'm certainly staying for the sprints. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 30.01.2012, 14:33 Uhr, schrieb Jan-Carel Brand : ... lots cut ... Yes, the values must be unique, because we do value lookups. The "title" attr doesn't have to be unique though. You could have a "Forestry" department for two different regions. The title will be the same, but the value and token attrs can't. I think the tests should be extended to show that this also includes nesting because this is non-obvious. ie. I believe that the region "Izmir" is within the state of "Izimir" in Turkey. This should be possible by calling _getPathToTreeNode during one of the passes through _flattenTree. getTermPath would then just need to do a lookup on this. I don't like the way the path_node gets implicitly populated during a call to _flattenTree. hm, okay. Personally, I think you should be able to populate your dictionaries with only a single pass through the terms. However, as this only needs to happen when the application starts we don't need to worry too much about the performance. I'd rather have a separate method that calculates the path and then explicitly assign it to self.path_node. In any case, there is now a node_index in the code >> but I don't see the advantage of >> cls.createTerm(*args) over SimpleTerm(*args) > See above. "createTerm" is there to let developers override it and > provide their own term objects. Do you have a concrete use case for this? Not really, but that doesn't mean it doesn't exist. Then someone will speak up for it if they need it or do their own subclassing/composition as required. Otherwise it's just food for warts. Remember that createTerm is a convenience method only. Frankly, I don't see the need for it in what is a fairly specialised class. I like consistency and symmetry, so if SimpleVocabulary has it, as an add-on developer I'd expect for TreeVocabulary to also have it. I don't however feel very strongly about it though, and I wanna get this done, so I removed it. Well, we could always think about removing it from SimpleVocabulary: it's not in the interface so no subclass actually has the right to depend on it. ;-) Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
in the SimpleVocabulary in such a way that
doesn't take the TreeVocabulary into account?
That would be the case with any subclass. In terms of maintenance it would
be easier to spot in case the changed behaviour was desirable.
but I don't see the advantage of
cls.createTerm(*args) over SimpleTerm(*args)
See above. "createTerm" is there to let developers override it and
provide their own term objects.
Do you have a concrete use case for this? Remember that createTerm is a
convenience method only. Frankly, I don't see the need for it in what is a
fairly specialised class.
As I said this is bike-shedding but I think our source code should be
written with a view to being read and probably copied verbatim.
With that in mind I prefer readability and testability over integration.
So why then cannot I copy "createTerm" from SimpleVocabulary?
For exactly that reason: just because someone writing application might
copy & paste your code is should be reason enough to make the code as
clean as possible and that does mean DRY.
In the end it tends to make things easier to use. The exceptions where
refactoring to
produce slightly uglier code but with significant performance hopefully
prove the rule.
Well, your suggestions concerning the nested methods had me thinking and
in the end resulted in significant refactoring. I think it was worth it
though, so thanks.
I've enclosed a diff with proposed changes.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226Index: src/zope/schema/tests/test_vocabulary.py
===
--- src/zope/schema/tests/test_vocabulary.py(Revision 124238)
+++ src/zope/schema/tests/test_vocabulary.py(Arbeitskopie)
@@ -305,27 +305,10 @@
except ValueError as e:
self.assertEqual(str(e), "term values must be unique: '1'")
-def test_overriding_createTerm(self):
-class MyTerm(object):
-def __init__(self, value):
-self.value = value
-self.token = repr(value)
-self.nextvalue = value + 1
-
-class MyVocabulary(vocabulary.TreeVocabulary):
-def createTerm(cls, token, value, title=None):
-return MyTerm(value)
-createTerm = classmethod(createTerm)
-
-vocab = MyVocabulary.fromDict(
-{(1, 1):{}, (2, 2):{}, (3, 3):{ (4,4):{} }} )
-for term in vocab:
-self.assertEqual(term.value + 1, term.nextvalue)
-
def test_recursive_methods(self):
"""Test the _createTermTree and _getPathToTreeNode methods
"""
-tree = vocabulary.TreeVocabulary._createTermTree({},
self.business_tree)
+tree = vocabulary._createTermTree({}, self.business_tree)
vocab = vocabulary.TreeVocabulary.fromDict(self.business_tree)
term_path = vocab._getPathToTreeNode(tree, "infrastructure")
Index: src/zope/schema/vocabulary.py
===
--- src/zope/schema/vocabulary.py (Revision 124238)
+++ src/zope/schema/vocabulary.py (Arbeitskopie)
@@ -138,6 +138,19 @@
return len(self.by_value)
+
+def _createTermTree(tree, branch):
+""" Helper function that creates a tree-like dict with ITokenizedTerm
+objects as keys from a similar tree with tuples as keys.
+
+See fromDict for more details.
+"""
+for key in branch.keys():
+term = SimpleTerm(key[1], key[0], key[-1])
+tree[term] = {}
+_createTermTree(tree[term], branch[key])
+return tree
+
@implementer(ITreeVocabulary)
class TreeVocabulary(dict):
""" Vocabulary that has a tree (i.e nested) structure.
@@ -157,6 +170,7 @@
widgets may be bound without subclassing.
"""
self.update(terms)
+self.path_index = {}
self.by_value = self._flattenTree(terms, {}, 'value')
self.by_token = self._flattenTree(terms, {}, 'token')
@@ -172,19 +186,6 @@
return False
@classmethod
-def _createTermTree(cls, tree, branch):
-""" Helper method that creates a tree-like dict with ITokenizedTerm
-objects as keys from a similar tree with tuples as keys.
-
-See fromDict for more details.
-"""
-for key in branch.keys():
-term = cls.createTerm(key[1], key[0], key[-1])
-tree[term] = {}
-cls._createTermTree(tree[term], branch[key])
-return tree
-
-@classmethod
def fromDict(cls, _dict, *interfaces):
"""Constructs a vocabulary from a dictionary with tuples as keys.
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 26.01.2012, 15:02 Uhr, schrieb Jan-Carel Brand : Ok, Charlie also expressed his reservations. I'll put it in a different package then. Hang on a minute! While I'm not 100 % convinced of the need in the core I think a separate package just for TreeVocabulary would be splitting hairs. If z3c.form can use it then I think that is justification enough. I'm not too sure what to name it though. For example, under what namespace? zope or z3c? I'm guessing zope.vocabulary, or rather zope.treevocabulary? Furthermore, for the dict class in use in the vocabulary, you could add a "factory" class that can be overriden easily. That would allow people with OrderDict capabilities to use them without having to re-sort later on. Could you please elaborate on what you mean? If I create a factory class to create TreeVocabulary instances, how will overriding that factory (without creating a separate SortableTreeVocabulary) allow people to use OrderedDict? Incidentally, I came upon this: http://pypi.python.org/pypi/ordereddict which provides the OrderedDict to Python 2.4 to 2.7 I think it might make sense to just subclass OrderedDict and implement an ordered tree from the start. I agree. Despite my previous remark about class methods, I don't think we need to worry much about Python 2.4 and 2.5 and ordered dictionaries are just so damn useful that they've been added to the standard library. Back to bike-shedding. As I was intrigued by the whole thing I've spent some time looking at the code. I'm not too happy on the use of nested functions as I find they obscure code, particularly when used recursively. I think that "createTree" and "recurse" should be written as separately testable generators. I also don't see a need for createTerm in this particular class and the subsequent awkward call from createTree. As it stands it is copy & paste both in method and test. If you must have it with the same implementation createTree = SimpleVocabulary.createTree does the job just fine but I don't see the advantage of cls.createTerm(*args) over SimpleTerm(*args) As I said this is bike-shedding but I think our source code should be written with a view to being read and probably copied verbatim. With that in mind I prefer readability and testability over integration. In the end it tends to make things easier to use. The exceptions where refactoring to produce slightly uglier code but with significant performance hopefully prove the rule. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 24.01.2012, 18:48 Uhr, schrieb Jan-Carel Brand : I've clarified some of the docstrings and added the missing one. None have doctests, perhaps you are referring to fromDict, which gives an example dict to show the required structure. I guess that could easily be turned into a doctest, I'll look into it. No need to add doctests. It was more a comment on the docstring of one method in comparison with the others. It would be nice to expand the README here. I don't see anything about vocabs there at all, but I'm willing to add some tests. er, just because the existing documentation is pants doesn't mean it can't be improved upon! ;-) I'm still not sure about having TreeVocabulary in zope.schema if it is only going to be used with, shudder, Archetypes. On the one hand schema are theoretically dissociated from any form library and zope.form is already incomplete, on the other we try and avoid application-specific requirements in the libraries. All the more important to expand the documentation so that other libraries can benefit from the plumbing. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.intid and zope.keyreference.interfaces.NotYet exception (patch)
Hiya, Am 23.01.2012, 23:20 Uhr, schrieb Cykooz : Oh ... Or there is no one who is engaged in package zope.intid, or no one gets an NotYet exception on the fault this package. Who can give me write access into SVN for the package zope.intid? You must apply to the Zope Foundation for access to the repository. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 24.01.2012, 12:35 Uhr, schrieb Jan-Carel Brand : Perhaps I should rephrase I would like my changes to be merged with the zope.schema trunk. The tests I've added provide 100% coverage of the TreeVocabulary code. I've only glanced cursorily at the source but I'm not sure that a merge is okay yet. At least not all of the methods have doc strings and one of them seems to have a doctest. It would be nice to expand the README here. getTerm is a copy of the SimpleVocabulary method. Using the @classmethod decorator is fine but inconsistent with other vocabulary classes. Using the decorator is more readable so I'd suggest changing all relevant methods to do that. Off the top of my head I don't know which Python versions support classmethods. That should be checked in case zope.schema is in a ZTK that is running on Python 2.4 I would just like someone to sign it off. Should I rather create a ticket on launchpad? Or otherwise, should I just go ahead and merge the changes to trunk? I would suggest going via launchpad if only because it is a better paper trail. At the moment I'm still not quite sure whether this is required in zope.schema. Do widgets only exist for z3c.form? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] merge zope.configuration dictactions branch
Hi Chris,
Am 05.12.2011, 04:02 Uhr, schrieb Chris McDonough :
On the zope.configuration trunk (and in all past releases), each ZCML
action is maintained as a tuple. The tuple can be of any length up to
seven elements, but mustn't exceed a length of seven. A complex system
of lengthening and shortening (in
zope.configuration.config.resolveConflicts) tries to ensure that the
tuple is of the smallest length required by chopping false elements off
the end of each action tuple during storage and reconstituting them to
7-element tuples during processing and sorting. I think this juke was
purely to make doctests easier to write, but I'm not entirely sure.
eek! I'm sure there was a better reason for this in the first place. As
things stand ZCML declarations are not orthogonal so a key-based approach
seems the better fit.
Up til now, pyramid_zcml could live with actions being at most 7
elements. But recent changes to the Pyramid trunk (adding
"introspectables") blew out the presumption that an action tuple could
be no longer than 7 elements (it now might need to be 8 elements).
Rather than extend the structure of the zope.configuration tuple with a
Pyramid-only "introspectables" argument, I've created the
chrism-dictactions branch
(http://svn.zope.org/zope.configuration/branches/chrism-dictactions/)
which changes ZCML action structures to be dictionaries. This allows
each action to contain arbitrary keys. This modification satisfies the
immediate requirement (adding "introspectables") and allows us to never
need to change the zope.config code again if more elements need to be
added to actions.
+1 as all ZTK test pass.
I could have instead added an "extras" dictionary on to the end of the
tuple as an 8th element, but it seems six of one a half dozen of
another, and the z.config code is much easier to understand when the
action is just a dictionary instead of a pseudo-struct.
I'm trying to think of where I've seen that pattern of {'organised'....
'others':{}} before... oh, yes in dodgy RDBMS schema.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Supporting interworking with repository branches on github
Hi Laurence,
Am 22.11.2011, 18:13 Uhr, schrieb Laurence Rowe :
> While the Zope Foundation deliberates on version control,
What's this about the Zope Foundation deliberating, why don't you just say
prevaricating?, on version control? I thought Tres presented a cogent
argument for maintaining the status quo and stick with svn.
> I think it's likely that development will continue using Git and Github.
Sounds like a self-fulfilling prophecy. FWIW the STD justification for
something ("everyone else has got syphilis so I want it, too.") is never a
good one.
Enough of the linguistic shilly-shallying. I do think that we need
something like PIPs or PLIPs for Zope 4 (jokingly referred to as ZIPs in
one of my recent posts) to work through some of the suggestions that have
been made.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
Hi Lennart, I'm not sure if you're not mixing different issues here. Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro : > Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, > not a part of moving to Zope 4. Different issues. I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
Am 16.11.2011, 15:15 Uhr, schrieb Christian Theune : > But they also have their merits. If I could make a wish, I'd like to see > a shared implementation that marries all the benefits. > Something I love a lot is the ++skin++ traverser for example. I also > like the idea of "tagging" the Request object with structured > information (an interface) to indicate specialisation. > I hate that I have to spell the layer in each ZCML statement. Smells like a "ZIP" to me. ;-) Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro : > Right. Could we standardize on skins or browserlayers plz? Having both > confuses the heck out of me. Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Products.CMFUid runtime issue
Am 23.09.2011, 09:44 Uhr, schrieb Ruslan Mahmatkhanov : > Patches are here: > https://github.com/mexicarne/zope/commit/1398afc68dd412d5dbe84f5fd5eadf0ae7a18c24 > Please consider to commit. I think CMFUid is still part of the CMF so this should really be directed to that list. Going by the current tests we're not yet up to Python 2.7 so it could be an incompatibility with that. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] access to create z.i and z.c releases
Am 23.09.2011, 09:36 Uhr, schrieb Chris Withers : > t tried zope.interface 3.8.0 on MacOS X Lion and got: Oh you brave boy! Given what Apple managed with Snow Leopard I've held off Lion so far and I always use the MacPorts toolchain. Works fine on Snow Leopard and builds with gcc-4.2 here. Maybe your Python was built with 4.0 or has some unrecognisable architecture flags? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Passing variable across pages
Am 21.09.2011, 16:24 Uhr, schrieb Joshua Immanuel : > After seeing this mail, I've started to think whether I should stop > cross posting in my future mails and which mailing list should I single > out. Please advice. Dear Joshua, cross-posting is generally unwelcome on any mailing list except for the purpose of announcements. While this list is primarily about the development of Zope, polite requests about real world applications are generally accepted assuming they are related to Zope or the ZTK. However, simply asking "I have this problem, how do I solve it" questions, and Bablyak's definitely fall into this category, are not in the spirit of the list. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] web sites are keep crashing
Am 26.08.2011, 15:27 Uhr, schrieb Babylakshmi Muthusamy : > Hi AJ, > I have moved one of the site's database from ZODB to mysql. Should I > have to > change any of the configuration? Hi Babylakshimani, that change has nothing to do with the problem. Does your Zope-user have access to files in /usr/local/zope/PPD/architecture/domains/ BTW. as you say you are new to Zope, what documentation have you been given. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
Am 26.08.2011, 09:51 Uhr, schrieb Wolfgang Schnerring : > However, what's important to me is that we try to make packages > cohesive, and that we try to make integration between packages > understandable. > The current zope.component, because it came out of the Zope3 monolith, > contains integration bits to various other Zope packages: > - zope.event > - zope.security > - zope.configuration > - ZODB > In that light, it makes a lot of sense to me to have two (or more?) > packages, "core" and "integration", but I'd *very* much like them to be > named in a way that one can tell this fact from their names. > What remains is the issue that zope.component *also* contains code for > the thread-local site concept -- which doesn't feel like an integration > with another package, but might not be considered core functionality, > either (I'm not sure yet but I lean towards considering it core). Wolfgang, I think that what you suggest is too much for the moment and I think it even contains the Zope 3 risk of trying to get everything right. I have the feeling that getting things right is going to take a lot more head-scratching and beard-pulling! Tres' proposal has the not inconsiderable advantage of merging work already done. You are right to point out inconsistencies and warts but against that should be weighed the possibility of making a port to Python 3.x a real possibility. And, given that the work has come from an external if related project, the main aim of exposing these libraries to the wider world has been achieved. So from +1 for Tres proposal and +1 for a roadmap on this. Regarding Withers suggestion - should we be looking to move these libraries to the WSGI namespace? Or are there real use cases outside the web world? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] getting size of zope.schema.List from a view in bluebream
Am 23.08.2011, 13:34 Uhr, schrieb Joshua Immanuel :
> This solves just the '__len__' issue. But if do the slice operation like
> this
>self.context.list_field[offset:limit]
> I get the following error
>ForbiddenAttribute: ('__getslice__',[...])
> I guess my approach is flawed. Implementing all the functionality (like
> the one I did for length) that a list provides is a overkill. So, please
> guide me in this regard.
Joshua,
I think it's really difficult to work out what you are trying to do.
Please state your problem more clearly. Are you still using zope.form or
are you using z3c.form?
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BlueBream] disabling zope.schema constraint check in edit form
Am 18.08.2011, 13:19 Uhr, schrieb Joshua Immanuel : > Yes. But considering the fact that I am doing this check at the > interface level. I wonder if that is ever possible, because the > constraint method knows just the value of the field. You can always go from the field to the object to which it is bound. Not sure if your constraint is actually the best way to go. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Am 05.07.2011, 14:44 Uhr, schrieb Jens Vagelpohl : > "zopefour" as a domain isn't very helpful. It would add yet another > "top-level" name to the existing list (Zope 2, Zope 3). > In the best of all possible worlds the package now known as "Zope2" > would simply be "Zope", and its website is at www.zope.org. "Zope" is > making the jump from version 2.x to 4.0. +1 Logically Zope 2.12 would have been a major release due to eggification and dropping Python 2.4. Only makes sense to make label the next major version as such rather than pretending with 2.x that only minor changes are being made. As I've been able to do little or no development this year thanks to Leonardo for raising this and Hanno for his explanation. I do think a public roadmap, with opportunities for people wanting to get involved would be a good idea. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. updating catalog indexes in bluebream
Am 23.06.2011, 14:43 Uhr, schrieb Joshua Immanuel : > I guess that I don't have to manually update the indexes each time when > an object is added/modified. Am I missing something? The indices do have to be updated every time you add, delete or modify an object. This is one of the reasons for the event system you were asking about the other week. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] component registry navelgazing
Am 13.06.2011, 17:01 Uhr, schrieb Chris Withers : > I have something, I want something that implements IWhatever. > Now, it may well be that something implements IWhatever, but it may > also not. As the author of the code in question, I don't want to have to > care. > Other authors can plug in adapters for the cases where something > doesn't implement IWhatever I can appreciate the use case but not the semantics - you are not looking for an adapter but an implementation. I guess this is related to the IWhatever(object) approach which does the magic for you. I guess queryProvider(object, interface) would be a better spelling for that use case, which may be more general than I'm suggesting. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] component registry navelgazing
Hiya, Am 12.06.2011, 22:48 Uhr, schrieb Chris McDonough : >>>> from zope.component.registry import Components >>>> c = Components() >>>> from zope.interface import Interface, implements >>>> class IFoo(Interface): pass > ... >>>> class Foo(object): > ... implements(IFoo) > ... >>>> foo = Foo() >>>> c.queryAdapter(IFoo, foo) > > In order to get the object itself back from such an adaptation, you need > to use the default= argument. I know that the question has been answered but your question makes me ask another: why would you want to adapt an object with itself? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Am 08.06.2011, 11:31 Uhr, schrieb Joe Steeve : > How do we get the list of subscribers for a particular event? By checking the registry for all adapters registered. from zope.component import queryAdapter queryAdapter(object, interface) ... # check the syntax and make sure you have the registry loaded. >> Why do want to disable notification? > We dont want to disable notification. We are just trying to understand > how zope.formlib works. We were of the understanding that every > 'request' starts and ends a transaction automatically (somewhere). So, > seeing this explicit notify() confused us. Note that adding a new object > does not require this explicit notify(). The transactional stuff does not happen in zope.formlib. Unfortunately zope.formlib is a bit opaque in the way it works. > Further, if we have to expect the developer to manually notify after > every change, it could invite unnecessary bugs. Which is why you should let the library handle this for you wherever possible and something you write tests for. > We are killing the server with a "Ctrl-C". Maybe something is not > getting flushed out to the disk yet? No, that is not likely to be the case. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hi Joe,
Am 08.06.2011, 11:05 Uhr, schrieb Joe Steeve :
> Supposing, we have a form action like:
>@form.action('Apply')
> def handle_edit(self, action, data):
> self.context.name += "Blah"
> This change is visible in subsequent requests. i.e if we view this
> object via another form, we can see the modification. However, if we
> restart the server (bluebream), this change is lost. The same thing
> happens when we use "form.applyData". If we 'notify'
> ObjectModifiedEvent, this does not happen.
> Since the object's modification is visible across requests, I am
> assuming that the transaction mechanism 'did' apply the changes to the
> object.
> But, it did not get to the disk :-/
I'm surprised at this but I'm not familiar with Bluebream's transactional
processing. The quickest thing to do is to reenable notification and add a
debug so that you can follow all the subscription calls and see what you
need to call.
Why do want to disable notification?
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
Hi Joshua, Am 08.06.2011, 10:34 Uhr, schrieb Joshua Immanuel : > Hello all, > I am using zope.formlib.form package for my forms, when overriding the > 'createAndAdd' method of form.AddForm I don't explicitly do the > zope.event.notify(ObjectCreatedEvent(..)) call. I just add the data to > self.context and it gets added (persisted) in the ZODB. Persistence is handled by the transaction management and is IIRC independent of the notifications system. Nevertheless, not calling the events is not advisable. > But when I extend the form.EditForm in order to implement my own > "Apply" action method, just calling the form.applyData or > form.applyChanges doesn't persist the data. > zope.event.notify(ObjectModifiedEvent(..)) call is needed in order to > persist data. > If someone could explain on this or point me to some documentation > relating to this would be very helpful to me. From memory I can recall something similar related to making changes to copies of instance attributes but failing to apply them to attributes and needing to specifically go context.attribute = form_result for the changes to persist. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)
Am 10.05.2011, 06:55 Uhr, schrieb Andreas Jung : > Constructive criticism and feedback is welcome _now_. Hi Andreas, along with others I'd like to thank you and the team for taking the time to do this. The new site has a clear message and looks good - not sure if the Zope logo should be repeated three times on the front page (surely the word mark should not be part of "The World of Zope") and there are some spelling issues "dekade" should normally be spelt with a "c"; Python can either be capitalised or written in quotes but not both... One thing that I think is missing on the resource page is a Products overview - PyPI isn't really suitable for someone wanting to see whether Zope (2) is suitable for them and despite what we now think about how to extend Zope, the Products do provide off-the shelf solutions for many situations; something that as developers we easily overlook. Something like the Plone directory, probably implemented as part of zope2.zope.org, but visible in the resources section. I suspect this means some kind of QS is required as only too many Products will no longer work with current versions of Zope and the onus must be with the Product author or maintainer. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogPathAwareness and zope.lifecycle
Am 17.04.2011, 17:15 Uhr, schrieb Sascha Welter : > Charlie, > I really like this quote from the Pyramid documentation: > "While the ZCA is an excellent tool with which to build a framework such > as Pyramid, it is not always the best tool with which to build an > application due to the opacity of the zope.component APIs." > - From my point of view, wearing my "application developer hat", > event handling is YAGNI. In my estimate > - - 90% of Zope Products/Apps only use manage_afterAdd or use none of > manage_after* > - - the other 9.9% use manage_afterDelete and/or some combination for > handling copy+paste. > - - The other 0.1% thought very hard to find something else they > thought they needed to do with events. Actually, I am big fan of events - yes, you don't need them very often but they do solve provide a useful solution to some fairly common use cases. Of course, as you point out they are often best wrapped up in a higher level component. I'm not sure what your point with the numbers is about - you think event notifications and subscribers are overkill given that pretty much only manage_afterAdd and manager_afterDelete are used? Maybe, but I think that's semantics. The important thing for me is that there is no magic. As to the larger point of how suitable is the component architecture for application development I think the main point that Chris is making, and I hope he'll correct me if this is not the case, is that doing everything with the ZCA, especially with registration is counter-productive: pluggability is not really a design goal for an application. > So a full feature, "we have it all for you" framework like Zope has been > doing fine to offer these few in an easy and simple way. Pyramid gives > me full event handling as an optional extra, because Pyramid is a "you > pay only for what you eat" framework and I might not even need those few > that Zope offers out of the box - or I might be in the 0.1% and need the > full deal. I beg to differ: Zope's SimpleItem is anything but and it's bastard Plonish offspring Archetype causes even more by offering convenience at the cost of complexity. Zope as a full-featured framework is a misconception: it is an application. > Interfaces is even more YAGNI in the role of the application developer. > (Which is what the pyramid doc is saying there IMHO.) Interfaces suffer most from conceptional vagueness. As an attempt to document the intent of classes they suck - that is pretty much what docstrings are for. I have found them to be most useful as: a) marker's and b) form schema templates. Of course, b) is something probably something they really shouldn't be used. Now I tend to see them as markers first with the possibility of being expanded to full-blown interfaces if pluggability becomes desirable. > I don't write a framework where you can swap out one templating system > for another, I just write an app that is finished at one point in time. I think everyone agrees on this nowadays. I do, however, like the ability to swap out the backend for deployment purposes if required. > As for Philip's book, I guess you are aware that lots of it is already > outdated. Something to keep in mind and tell people when one recommends > that book. (Philip is well aware of that and his "in hindsight, the book > should have been free/open" blog post is quite interesting.) Some of the detail is pretty much out of date but I still think it is a great handbook on the component-based approach to application development. Speaking as someone who has no CS background and is only a part-time programmer I found it incredibly helpful in structuring my approach to problem solving and really benefited from the extensive explanation of some of the more esoteric stuff that has now become more or less standard. >> @Sascha I'm not sure if this will answer your question but you might >> want >> to look at how Products.CMFCore.CatalogAware works. > Thank you. > This would answer my question if someone told me to take over > maintenance of CatalogAware / CatalogPathAware in Products.ZCatalog > and I'd have to rewrite it instead of just writing tests and if I then > asked the question "where do I start?". I think I detect some irony there. Sorry that it doesn't help you. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogPathAwareness and zope.lifecycle
Am 17.04.2011, 16:08 Uhr, schrieb Sascha Welter : > The term "CatalogPathAwareness" was not found in the archives of > zope-dev in the last 6 years or so. Can any zope developer deprecate or > remove things on their own without discussion? Technically, yes. In general there is usually a request on the mailing list because another developer could just as easily put the removed feature back. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogPathAwareness and zope.lifecycle
Am 17.04.2011, 13:46 Uhr, schrieb William Heymann : > I have spent some time looking at other frameworks and most just don't > look very promising to me. For grok my biggiest issue was fail open. It > looks like the default is allow everything unless explicitely denied and > I feel that is just a recipe for disaster. Pyramid looks pretty good and > it does have a > security system that you can set to fail closed but still I have a > massive investment in zope 2.x and I don't want to just throw that away > for nothing. We still manage to massively outdo our competitors using > much newer technology in time to get a solution done, in cost and in > reliability. > So I would just like to see zope 2.x remain a viable platform and if > things > are to be removed or deprecated the replacement systems need some level > of docs. Idealy, if I could, I would make it so that varous > manage_before* and manage_after* type events would just call the > zope.lifecycle stuff as a > compatibility layer so all the old code would go away but old apps would > work and the code itself would serve as instructions on how to upgrade. > That way CatalogPathAwareness would stay but basically just be a wrapper > for zope.lifecycle if that is possible. Hi, it would be great to see the things happen that you wish but the fact is Zope 2 has lost most of its developers already. If you want something in there you have to be prepared to do it yourself. I'm still a huge fan of everything that Zope achieved and agree with you totally that it is still more capable in many respects than many competitors but the world has moved on and it is important to move with it. Zope 2 is largely in maintenance mode with things being removed from the core because there is no one prepared to maintain them and they are not considered essential by those who are maintaining Zope 2 and making sure it can run on modern systems, etc. I, for one, are very grateful that this work is being done. As for an explanation of how to use events or simply getting a grasp of using the ZCA in Zope 2 I can highly recommend Philip von Weiterhausen's book on Zope 3. In many ways this is the missing Zope manual. Fortunately, many Zope inspired projects have learned from our consistent failure to provide good documentation and insist on it being part of the project. A brief and personal summary of the difference between events versus "magic" manage_* methods: events are explicit, ie. you must register a subscriber to a particular event or explicitly notify that an event has happened. This is perhaps a bit verbose but it gives you more control and helps you break functionality out of bloated classes. The signatures for event subscribers does take a while to learn but is reasonable. I suppose that it would be possible to scan source code automatically for manage_* methods and try and register subscribers on the fly but this would be against the spirit of the ZCA. In reality decorator-based registration as practised in Pyramid and Grok is a good compromise. @Sascha I'm not sure if this will answer your question but you might want to look at how Products.CMFCore.CatalogAware works. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
Am 20.03.2011, 18:07 Uhr, schrieb Tres Seaver : > The one downside I can see is giving up on the sugar^Wexpressivity of > calling the interface directly -- I guess we could propagate the > 'default_factory' argument through to the '__call__' of interface. Note > that I *wanted* some extra sugar at one point (doing utility lookup when > no arguments were passed to Interface.__call__), but I haven't missed > that convenience much since I went on a low sugar diet with BFG / > pyramid. Callable interfaces are, in my view, a huge wart with a pimple on top! Convenient, yes, but just try and explain why a specification against which "living" code should be built should itself be executable. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Am 21.03.2011, 20:33 Uhr, schrieb Tres Seaver : > FWIW, I just added 'queryAdapterFactory' and 'queryMultiAdapterFactory' > APIs to zope.component on a branch: > http://svn.zope.org/zope.component/branches/tseaver-queryAdapterFactory/ > These APIs make the "almost never overridden" / dependency injection > case as compact for adapters as for utilities. This is an excellent suggestion! Being able to supply a default implementation that is easily overridden by a configuration is clean and easily understood and avoids both clumsy code checking and configuration. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fwd: Re: plans for tonight
Am 12.03.2011, 21:47 Uhr, schrieb Tres Seaver : >> Jeff Rush planning a P <http://twitter.com/#!/search?q=%23pycon>yCon >> open >> space "What's wrong with Zope" at 6:30pm today. He's looking for >> constructive criticism, ideas for progress. >> >> After that we're planning to go to dinner at around 7:30pm after that >> to a >> nearby Mediterranean restaurant. I'm planning to make reservations at >> the >> restaurant, so please let me know if you'll be attending. >> >> Feel free to forward to friends who you think might be interested in >> either/both events. Sounds like an excellent idea. Such a pity that there is not a dedicated mailing list for PyCon attendees. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Sprints at PyCon
Am 10.02.2011, 07:07 Uhr, schrieb Christian Theune : > Who's coming? Who's interested? Any topic suggestions? I'll be there and hoping to finalise my work on CMF so that we can release 2.3 Is anyone bringing copies of the DZUG Brochure on Zope? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
Am 04.03.2011, 08:58 Uhr, schrieb yuppie : > If we always send UTF-8, their current implementation doesn't make much > sense to me. Don't know if we really should try to fall back to all the > charsets mentioned in Accept-Charset. But at least we should *always* > try UTF-8 decoding first. Hiya, I'm not sure if this is directly related but I remember Withers having a discussion (alright, shouting match) with Andreas about cycling through all kinds of encoding possibilities on the resolver. I can't find the thread at the moment but I think it related to the way templates could be edited TTW or how to handle situations of mixed encoding. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
Am 02.03.2011, 12:29 Uhr, schrieb yuppie : > getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is > accepted. > If 'utf-8' is not in getPreferredCharsets(), it is not very likely that > the browser speaks UTF-8 and processInputs will not even try to decode > with UTF-8. In that case it might be better to respond with an accepted > encoding. I think you are drawing the wrong conclusion - some browsers (Internet Explorer and Safari spring to mind but this will also be the behaviour in Opera from 11.10) simply don't have an accept-charset header and the W3C says this means you can throw anything at them, in which case UTF-8 is a good choice. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] string exceptions
Am 25.02.2011, 12:26 Uhr, schrieb Hanno Schlichting : > +1 - if you really feel like it you could backport to 2.12 branch as > well (as it only supports Python 2.6 too). - 1 against backporting unless you are experiencing the errors on a 2.12 based system. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
Am 11.01.2011, 22:44 Uhr, schrieb Tres Seaver : > Python 2.5 isn't even getting security fixes from Python devs now, which > means that Debian users are holding more risk than they know (I strongly > doubt the Debian packagers of Python are up for backporting all the > potential security fixes in the 2.6 / 2.7 lines). I understand that and I don't understand Debian's policy - maybe after they move to a better kernel (no, don't bite...) they'll start following a better release policy as well? But this was precisely the reason cited for keeping support for 2.5 in the ZTK > 1. I find this somewhat contradictory. To the extent that there may well be people out there with existing servers that are dependent upon package management and, therefore, less likely to want to roll their own Python install, this makes sense. So +1 on yuppie's initial suggestion for a 2.12 compatibility marking. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
Am 04.01.2011, 14:25 Uhr, schrieb Hanno Schlichting : > With the current roadmap, we'll > likely be able to stop using Zope 2.12 in 6-9 months altogether. I've given this some thought: as long as Python 2.5 is the default install on Debian-based systems, as it currently is, you can't really go beyond Zope 2.12. This was the reason why support for Python 2.5 wasn't dropped for the ZTK > 1 Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Weekly Meeting
Hi, Theuni is still away - presumably pining for snow on some sun-drenched beach - you've got to make do with me! Weekly developer meeting today, 14th December, at 15:OO GMT/UTC on #zope Possible topics: * next bug day * ironing out bugs reported by the buildbots. See you then! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] My bug day wrap-up
Am 06.12.2010, 22:35 Uhr, schrieb Charlie Clark : > I don't have an account and I've never made a release. I've just tested the svn checkout of zope.publisher with a Zope 2.12 + CMF-based site I have and the change does what it should: where Zope was previously guessing latin-1 for Safari and Internet Explorer and raising unicode errors it now publishes happily! Could you do the release? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 78 OK, 5 Failed
Am 09.12.2010, 14:42 Uhr, schrieb Marius Gedminas : > When can we have the new pretty summarizer? Presumably not before Theuni gets back from holiday. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] My bug day wrap-up
Am 05.12.2010, 20:58 Uhr, schrieb Marius Gedminas : > I can make you an owner on PyPI, if you tell me your username. I don't have an account and I've never made a release. > Also, please mention the change you made in CHANGES.txt. Done, thanks for the reminder. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Dev Weekly Meeting
Hi, as Theuni is on holiday for two weeks I'll be convening the weekly Zope dev meeting on IRC#zope tomorrow, 7th December at 15:00 UTC. The agenda is still open if you've got anything in particular you want to talk about. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] My bug day wrap-up
Am 29.10.2010, 11:41 Uhr, schrieb Charlie Clark : > Could someone please release an update for zope.publisher for this? I'd > like this change to be in Zope 2.13 if possible. Bump - could someone please release an updated version of zope.publisher Thanks Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
Am 03.12.2010, 11:51 Uhr, schrieb Malthe Borch : > It's not always possible to control the order of execution. For > instance, with z3c.autoinclude, the order of inclusion is somewhat > random and although you can to some extend control the order via > explicit dependency includes, it's hard to work around 3rd party > packages that provide own overrides. Sounds like a bug in autoinclude to me. > The problem with e.g. request layers as a means to prioritize is that > views adapt on (context, request) which makes it unfit for the purpose > if you have any views that specialize on the context interface. I don't understand this sentence. Are you talking about layers as in the Zope 3 skin layer? Otherwise I've nothing but good experiences with views using interface subclassing for specialisation. > Instead, priorities on the configuration level would be an easy > solution if you are trying to simply get a component to kick in. As Marius has already noted, this sounds very much like adding more complexity to solve the apparent existing complexity: swallowing the spider to catch the fly. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
Am 02.12.2010, 14:19 Uhr, schrieb Malthe Borch : > As far as I understand, for a ZCML include override to work properly, > you need to carefully make sure that your includes are in the exact > right order and on the same level. In a system where two packages are > trying to override the same component (should arguably never be the > csae, but it is frequently), it can be difficult to get it right. > Priorities on the other hand are absolute, globally. It's easy for > anyone to see that the highest priority wins, no matter the order of > inclusion. -1 on priorities - how do you resolve the case where the priorities are the same? The proposed solution introduces an additional complexity which could get even more baffling than the current one. I would much prefer a cascading/layered/subclass approach but I suspect this might not be possible with the current implementation, so I sympathise entirely with your complaint. As a developer you kind of imagine that your application layer ought to "win" just as your subclass "wins". Can we get some kind of diamond rule? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug day and IRC meeting
Am 30.11.2010, 16:47 Uhr, schrieb Christian Theune : > However, I'm looking forward to a two-week holiday, so I won't be > present at the meetings next week and the week after. I'll be back at > the meeting on 2010-12-21, though. I should be able to sit in for the next two meetings and will be travelling 21st December. I've started work on my improvements to zope.bugtracker. However, it looks like it's trickier than I imagined: we want to get a list of the most recent checkins on a project and, thus, need the repository URL. Unfortunately, unless I'm missing something, this isn't available from launchpad so all we have are naming conventions. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Weekly meeting
Am 23.11.2010, 15:08 Uhr, schrieb Christian Theune : > Hi, > I'm short on time right now and didn't manage to write the minutes from > last week and won't be able to attend this week. I can chair the meeting today but I wouldn't be so good at writing up your notes from last week. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Developer IRC meeting on Tuesday 15:00 UTC
Am 12.11.2010, 14:10 Uhr, schrieb Christian Theune : > Hi, > this week didn't see a meeting, AFAICT from the logs. I was there on my lonseome. > So I'm picking up > where we left a while ago and would suggest we check for: > - input from people who attended the Plone conference > - input from people who attended the grok sprint > - An update on the repository policy? There's a nagging script supposed >to appear ... > - summit goals We also need to to pick the next bug day and follow up on the last one. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface memory optimization
Am 10.11.2010, 01:40 Uhr, schrieb Brian Sutherland : >> > On the micro benchmarks, the only difference I see is a memory >> > improvement which I think will not survive in practice because most >> >> ... ? > Er, somehow my thoughts didn't make it into text: > attributes are zope.schema fields (i.e. subclasses of Attribute). > To really make that work, you'd have to add __slots__ to most of the > classes in zope.schema as well. It might be purely academic but if this does significantly reduce memory use then it might be worth pursuing. Slots are supposed to be beneficial when you've got lots of objects around. Zope schema fields are pretty static anyway so I don't see a great penalty in having to add slots to them, although obviously a migration of a larger project would probably be a pain. Back to the micro-optimisation. At Jeff Rush's talk at PyCon this year he covered the penalties incurred by "." lookups so that might be something that could be investigated but might it also be possible to "memoize" the method calls? I keep forgetting when you can't do that. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface memory optimization
Am 08.11.2010, 15:35 Uhr, schrieb Brian Sutherland
:
> If no-one replies, I'll assume that 3% is just not enough to be
> interesting and do nothing;)
Hi Brian,
thanks for sharing this but it looks to me like a micro-optimisation that
isn't really worth going against best practice for - by using explicit
name-mangling.
-return self.__tagged_values.get(tag, default)
+return getattr(self, '_Element__tagged_values', {}).get(tag,
default)
Any improvements higher up the stack (using slots, different Python
version or compilers like LLVM) are likely to have a more significant
effect. Might be worth timing a slots-based implementation.
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Developer meeting next Tuesday at 15:00 UTC
Am 04.11.2010, 14:29 Uhr, schrieb Christian Theune : > Hmm. It's either been DST confusion or Plone Conference exhaustion, but > Marius and me were the only ones but didn't discuss anything. I was dragged into a customer appointment so couldn't make it but the public holiday in *this* part of Germany on Monday had also totally thrown me. > I won't be there next week unfortunately, as I'll be travelling for a > customer. (I *might* be there but with only a very slight chance.) > Charlie? Can you take over? I should be able to, yes. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Developer meeting next Tuesday at 15:00 UTC
Am 29.10.2010, 15:26 Uhr, schrieb Christian Theune : > Hi, > for next week's meeting (#zope on freenode, as always) I propose to hear > from the PloneConf, check with the summit goals, and follow up on the > bicycle toolkit again (Charlie, you coming?) Hi, yes, I'm back in Germany now and will be there on Tuesday. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] My bug day wrap-up
Am 26.10.2010, 16:29 Uhr, schrieb Charlie Clark : > I've just submitted a change to that old chestnut > https://bugs.launchpad.net/zope2/+bug/143873 Could someone please release an update for zope.publisher for this? I'd like this change to be in Zope 2.13 if possible. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] My bug day wrap-up
Am 26.10.2010, 16:20 Uhr, schrieb Christian Theune : > So, what's up for everyone else who joined the bug day? I've just submitted a change to that old chestnut https://bugs.launchpad.net/zope2/+bug/143873 If ACCEPT_CHARSET isn't present or empty we set UTF-8. The W3C spec is the browser is happy to take anything and UTF-8 is the only charset that we can all use. I'm now going to skulk over to the CMF and see if I can fix the breakage introduced by Laurence's recent merge of his branch. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
Am 26.10.2010, 16:13 Uhr, schrieb Tres Seaver : > I prefer the latter, and don't think we need a deprecation cycle for it: > if the call site is passing in a mapping, that is presumably more > specific than anything stored in the catalog. I can't see how we would > break anything here, as nobody is likely to have actually used the > feature (since it is effectively a no-op). +1 Some additional justification - it's inconsistent to have different behaviour for message id's and local strings plus it basically defeats the purpose of domains if you can't override the system values in the application. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 and devmode ZCML feature
Am 26.10.2010, 12:12 Uhr, schrieb Sylvain Viollon : > As far as I know it is not available in Zope 2 (where only > Globals.DevelopmentMode, or App.config.getConfiguration()... is > available). > I don't think it is very difficult to add and I know that would make > my code much more readable. As we are supposed to be able to use development mode anyway this makes sense so +1 from me. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug day next tuesday, 2010-10-26
Am 19.10.2010, 18:42 Uhr, schrieb Christian Theune : > another bug day! I've picked next Tuesday based on the input from the > Doodle (Charlie and me) and the IRC (Tres). For family reasons my time is limited tomorrow but I'll put as much time into this as possible. There are a couple of CMF issues that I can look at including the current break to CMF + Zope 2.12 Otherwise I'll try and look at extending the bugtracking script as agreed with Theuni several months back. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Another weird unicode error from Zope 2
Am 13.10.2010, 12:57 Uhr, schrieb Chris Withers : > I don't have one set. > So, is iso-8859-15 the default in Zope 2.12? If so, why on earth that > rather than utf-8? See Zope2/Statup/zopeschema.xml This key controls what character set is used to encode unicode data that reaches ZPublisher without any other specified encoding. iso-8859-15 As to why it is iso-8859-anything as opposed to utf-8 is presumably because it has historically been the case. I don't know what would break if this would change. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Yet more unicode and page template weirdness
Am 13.10.2010, 09:53 Uhr, schrieb Chris Withers : > Any ideas where the non-ascii character is in the above? Either this is a trick question or I'm just not getting it. 203a is the hex value of the decimal 8250. >>> hex(8250) '0x203a' Maybe your question is actually why is the XML entity being converted to character data at all? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Another weird unicode error from Zope 2
Am 13.10.2010, 12:06 Uhr, schrieb Chris Withers : > So why on earth is iso8859_15 being picked instead of utf-8? I would guess this is the default-publisher-encoding of your system. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fun with vocabularies
Am 07.10.2010, 14:50 Uhr, schrieb Charlie Clark : > Thanks for the tip. For a vocabulary it has to provide IBaseVocabulary as > well, although I guess I can just define a source. Unfortunately I'm > getting now getting an AssertionError when the widgets are setup but I > now > know where to look. Just for the archives def my_source(context): ... return SimpleVocabulary() directlyProvides(my_source, IContextSourceBinder) works fine with class IMySchema(Interface): choices=Choice( source=my_source ) NB. that you must use "source" and not "vocabulary" for this to work. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.buildout/buildout.org down -> disaster
Am 12.10.2010, 17:12 Uhr, schrieb Hanno Schlichting : > Are you sure you used the latest distribute release? I hadn't had any > problem at all during that whole time. I had it here with the CMF buildout and also got it in a report from a customer. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Another weird unicode error from Zope 2
Am 12.10.2010, 16:51 Uhr, schrieb Chris Withers :
> UnicodeEncodeError: 'charmap' codec can't encode character u'\u203a' in
> position 2439: character maps to
Hi Chris,
according to http://wiki.python.org/moin/UnicodeEncodeError this is what
you get when you try and encode a unicode codepoint to a charset which
cannot represent it. The error message appears to depend upon the charset:
>>> u'\u203a'.encode("iso-8859-15")
Traceback (most recent call last):
File "", line 1, in
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/iso8859_15.py",
line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u203a' in
position 0: character maps to
>>> u'\u203a'.encode("latin-1")
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'latin-1' codec can't encode character u'\u203a' in
position 0: ordinal not in range(256)
ISO-8859-15 is, of course, Latin-1 + the €
Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PAS CookieAuthHelper and insufficient privileges
Am 12.10.2010, 02:21 Uhr, schrieb Laurence Rowe : > Yet another option would be to let logged in unauthorized to percolate > up and implement that page with an error view. > Any opinions? I'm leaning towards adding an insufficient_privs_path as > it seems simplest and least invasive. (When not set it would just use > login_path as normal). I don't know whether this is relevant but Yuppie's refactoring of CookieCrumbler (proposal 20th April 2010) for the CMF uses Exception views and they work very well. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 20% slower than Zope 2.9?!
Am 11.10.2010, 14:16 Uhr, schrieb Chris Withers : > The site is classic Zope 2: zodb-based python scripts and page templates > building the UI from Product-based content objects. > Have others shared this experience? Hiya Chris, I haven't run any performance tests but my Zope 2.12 feels quite a lot faster to me than pre-buildout versions. I thought there were some comparative figures upon release? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fun with vocabularies
Am 07.10.2010, 14:58 Uhr, schrieb Fred Drake : > Interestingly, I can't find anything that suggests "consolidation" by > searching that page for "mail" or "list". Was that what > "IRC/mailinglist rationalisation" means? Yes, that's the one. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fun with vocabularies
Am 07.10.2010, 14:34 Uhr, schrieb Fred Drake : > Have you tried using a callable that provides > zope.schema.interfaces.IContextSourceBinder? > Looking at the code in 3.7.0 (the newest zope.schema in my egg cache), > that should work out of the box. Thanks for the tip. For a vocabulary it has to provide IBaseVocabulary as well, although I guess I can just define a source. Unfortunately I'm getting now getting an AssertionError when the widgets are setup but I now know where to look. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fun with vocabularies
Am 07.10.2010, 14:38 Uhr, schrieb Fred Drake : > Another consolidation? We already tossed the zope3-dev list. This was the suggestion at the summit: http://wiki.zope.org/ztk/ZopeSummit2010Summary Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fun with vocabularies
Am 07.10.2010, 14:31 Uhr, schrieb Hanno Schlichting : > No offense, None taken. > but isn't this a question for a users mailing list? It's > not really about developing Zope itself, but developing with Zope > isn't it? I thought we were consolidating the mailing lists? It is a developer's rather than a user's question but I would agree not related to ZTK development. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Fun with vocabularies
Hi, I was wondering whether it's possible to use callables for schema vocabularies without registering them first? ie. def my_vocab(context): while some_constraint: yield zope.schema.SimpleTerm() alsoProvides(my_vocab, zope.schema.interfacesIBaseVocabulary) class IMySchema(Interface): value = Choice( vocabulary=my_vocab ) I'm sure it should be possible but my weak and feeble brain has somehow failed to solve the puzzle! On a similar note: how should I handle i18n message objects that are the title of a SimpleTerm? At least in zope.formlib this leads to a rendering error because: "AttributeError: 'MessageFactory' object has no attribute 'replace'" Thanks for any pointers. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Developer meeting next Tuesday at 15:00 UTC
Am 05.10.2010, 13:51 Uhr, schrieb Charlie Clark : > Shit. I have a doctor's appointment at 13:00 UTC. I hope I am back in > time > but if not can I ask Adam to step in? Okay, I made it back in one piece. In addition to any post-summit follow-up - and there have been very few additions to the task list( http://wiki.zope.org/ztk/ZopeSummit2010Summary) - I'd like to talk about the next bug day. See you all in half-an-hour. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Developer meeting next Tuesday at 15:00 UTC
Am 05.10.2010, 07:44 Uhr, schrieb Christian Theune : > Me bad. My scheduling isn't good enough it seems. I need to be on the > road at 3pm UTC today and won't be there. :/ > Charlie? Shit. I have a doctor's appointment at 13:00 UTC. I hope I am back in time but if not can I ask Adam to step in? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug day report
Hi, I'll admit to spending most of my time on new CMF stuff but I did close two bugs that I felt comfortable with. Didn't seem anyone else was hanging around on IRC with bugfixing on their mind. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
