Re: [Zope-dev] Tests results for Zope 3.5dev KGS
On Mon, Feb 09, 2009 at 10:52:01AM +0300, Dan Korostelev wrote: 2009/2/9 Dan Korostelev nad...@gmail.com: 2009/2/9 Stephan Richter srich...@cosmos.phy.tufts.edu: Anyone, how close are we to a z3c.form 2.0 release? I worked on the multi widget a little some time ago, adding conditional add/remove buttons. However, there are still some (not too important though) TODOs on it. Also, there's a really strage bug with macros when using z3c.pt discovered in tests/simple_groupedit.pt. I leaved a comment there [1], I guess that's for Malthe. :-) I think, I'll try to make a review of current z3c.form's state and write more on that. [1] http://svn.zope.org/z3c.form/trunk/src/z3c/form/tests/simple_groupedit.pt?view=auto Oh, also, I guess it should use z3c.ptcompat rather than z3c.pt.compat for z3c.pt thing. I have a branch for that, but am blocked on merging that because the z3c.ptcompat code has test failures (in itself and z3c.form). These test failures existed before I moved z3c.pt.compat to z3c.ptcompat. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
Stephan Richter a écrit : On Sunday 08 February 2009, Christophe Combelles wrote: For now I only have the py2.5-64bit slave, but I have similar results, though less tests: http://zope3.afpy.org/buildbot/ 12895 tests, 27 failures, 10 errors I'll add other slaves soon (32bit and py2.6). Fantastic! That's great news. BTW, I think you can take Py3.0 from the list, since we are not aiming at supporting it yet. It doesn't eat any time or CPU since it doesn't work, so I'll leave it here, think of it as some sort of reminder :) As soon as we'll have virtualenv, buildout and setuptools released for 3.0, we will have a first sight on the global status on this topic. Christophe (working on setting up a 32bit slave, either on qemu or another machine) I think several problems are shallow: - Restricted Python fails for strange reasons. Installing the trunk as devel egg works. I think it has something to do with Sidnei making the latest release and he is on Windows. - The z3c.form issues should be fixed in trunk. Anyone, how close are we to a z3c.form 2.0 release? (Mmmh, I guess I should know. ;-( Adam? Roger? Dan? Malthe?) - Several other packages fail because they have not been adjusted to the latest refactorings. Those are the low-hanging fruits I think. Regards, Stephan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] multiple packages in the same namespace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Christian Theune wrote at 2009-2-7 09:36 +0100: ... According to the setuptools documentation and our experiments on the sprint, this is supposed to work and does work: When you declare a package to be a namespace package, it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages. If so, which packagea/__init__.py gets used? Only the __init__.py isn't allowed to have code is what I read from the documentation. However, extreme care must be taken to avoid name clashes. As with any namespace, sure. But there would be no point in namespace packages at all if modules or subpackages couldn't be placed in them. For Modules/packages with the same name it is not deterministic which of them will actually be loaded. __init__.py is just a common case of this problem. It is the one which is guaranteed to clash, since its absence makes a directory not-a-package at all. Setuptools documents that every directory participating in a namespace package must have the declare a namespace boilerplate in its __init__.py, and *nothing else*. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkEhY+gerLs4ltQ4RAqxIAJ9ds65eHMxyMFjltbPrSglCe03KHQCfVSyS UHJV4bm84NLy29xhNJzfz8o= =6Htc -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Planning for Zope 3.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hermann Himmelbauer wrote: Am Sonntag 01 Februar 2009 07:51:43 schrieb Stephan Richter: Hi all, now that we have Zope 3.4.0 finally behind us, let's look forward. As I said in the release notes, I am really willing to switch to a 6 months release cycle again. I think there are three areas that we can work on: - Python 2.6 support. - Dependency reduction. - Improve project setup Yes, I'd also suggest this. What I'd also like to have is: - More focus on z3c.form/z3c.pagelet and less on the ZMI. - More focus on SQLAlchemy integration. And something I wonder from time to time is if it would be possible to integrate a recent Twisted release into Zope3, or, even better, directly use the current twisted egg with Zope3. I would rather move the Twisted support out into a non-core package, and focus on making the Zope3 components play nicely with *any* WSGI-compliant server. The fact that we still have a forked Twisted in Zope3 is directly tied to the absence of a crucial component in the released version of Twisted. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkEjl+gerLs4ltQ4RAl4pAKCET8mNIdimYzpuiPegRY4gpeXBaQCfXdzC JDsA2cClJ1OfStL5QqA6ZKA= =/OZS -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
On Monday 09 February 2009, Brian Sutherland wrote: Oh, also, I guess it should use z3c.ptcompat rather than z3c.pt.compat for z3c.pt thing. I have a branch for that, but am blocked on merging that because the z3c.ptcompat code has test failures (in itself and z3c.form). These test failures existed before I moved z3c.pt.compat to z3c.ptcompat. Check it in; it will save Dan some time. ;-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
On Sunday 08 February 2009, Dan Korostelev wrote: I think, I'll try to make a review of current z3c.form's state and write more on that. Thanks a lot! Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: [snip] Anything you'd actually be +1 on? :) I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever. I thought significant process was made on the ability to reuse more handlers now that Zope 2 has got __parent__ support. Not enough? Grok has different needs for the configuration part of your application. Grok does reuse some actions defined for the use of ZCML actually, though sometimes we do introduce new ones. repoze.bfg takes yet another approach. I'm sure there are new ZCML directives it introduces, but it also forked the current ZCML directives that are in zope.component for basic component registration, to reduce its dependencies. Perhaps that fork can be undone if we improve the way we break things down (to anticipate what you're saying below). The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be one global component registry to rule them all, which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes. Once we define a Grok-like API for Plone we will probably end up with yet some other kind of different semantics. If you define altogether new actions that are Plone specific there might not be too big of a problem in overlap there. My gut feeling is that the best long term answer would be to figure out how to split zope.configuration and ZCML kind of in the middle. What parts of application configuration are actually reusable and which are not. Reusable configuration is a bit of an oxymoron: if everybody *must* use the configuration, then it isn't configuration at all, but software. I think, however, that this discussion is about where to put the meta bits (the parts which actually implement ZCML directives), rather than rehashing the library vs. application problem (where to put the configuration). How does application configuration and system configuration like paste.ini and zope.conf fir together? Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer. I'd consider it at least a necessary step towards a long term answer, so you should be +1 for step one. :) Another step would be to start taking a look at refactoring the actions to increase reuse. I think refactoring the actions can be driven by the needs of the code that uses it. If Zope 2 developers say: hey, we could *almost* use this action if it only didn't do this, we could use that to split the action into two parts so that the main part can be reused. The Grok developers and Repoze developers should look for similar opportunities. It might be that some actions very similar to the ones the repoze fork now uses will make it back into zope.component, but that the extended ones that Zope 3 requires should be extracted. Note that I don't mind much that zope.configuration has intrinsic support for ZCML (besides the general action-based configuration system). Grok needs that support anyway, and so will any system that at least wants to support packages that load their configuration using ZCML. I would argue that putting any ZCML-related implementation in a separate package from the zope.component core would be a win, at least from the perspective of clarity and dependencies. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkE3v+gerLs4ltQ4RAvbxAJ40EfLHA+l/8ixXFmuVQJO9e15QYQCcDazx rGxL8+ZQpfxnAPbGLV1O0GM= =mutG -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Hey, Tres Seaver wrote: [snip] repoze.bfg takes yet another approach. I'm sure there are new ZCML directives it introduces, but it also forked the current ZCML directives that are in zope.component for basic component registration, to reduce its dependencies. Perhaps that fork can be undone if we improve the way we break things down (to anticipate what you're saying below). The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be one global component registry to rule them all, which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes. Cool, I hadn't realized that. I think it would be useful to fold that support into the Zope framework itself too. [snip] Reusable configuration is a bit of an oxymoron: if everybody *must* use the configuration, then it isn't configuration at all, but software. I think, however, that this discussion is about where to put the meta bits (the parts which actually implement ZCML directives), rather than rehashing the library vs. application problem (where to put the configuration). Yes. My interpretation of what Hanno said was that he was talking about reusing the implementation of configuration. I.e. repoze.zcml might define an action that zope.componentconf might use in the implementation of its own actions. Anyway, no matter what Hanno said, I think that is an interesting area to explore. Grok and Five both want to reuse as much of the underlying action implementation in the Zope framework as possible. [snip] I would argue that putting any ZCML-related implementation in a separate package from the zope.component core would be a win, at least from the perspective of clarity and dependencies. Agreed. It might be that the core implementations of actions a-la repoze.zcml could be moved into zope.component. repoze.zcml could then become a smaller package that simply registers the directives themselves for these actions. We could then have something that builds on this (and zope.security) to implement the directives that zope.component now implements. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] opensp...@pycon 2009 about Zope/Repoze/Grok/Deliverence etc.
Lots of things have happened in the Zope universe the last couple of years, and are still happening, some of which are turning Zope inside out, from a monolithic ghetto to a componentized agile speed monster. People outside the Zope world doesn't know about it, and although the Zope community mostly seems to be on the same page, I think it would be nice if we get as many as possible together to discuss the status and where things are going. And, if we don't have anything to discuss, we can drop off to some bar and toast at how great Zope is. :-) So, I propose to have an Open Space session at PyCon, Chicago, March 27-29 . As this is a part of the unconference bit of PyCon, you don't have to sign up, but you can say if you are coming here anyway, just so we get a feeling for the interest. And although we can't decide when to do this yet, if you are only able to go to PyCon certain days, say so here, so we'll know when we can get the most participants. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Hello, Monday, February 9, 2009, 5:58:34 PM, you wrote: The fork is not merely to reduce dependencies: BFG also wants to eliminate the requirement that there be one global component registry to rule them all, which is pretty deeply embedded in zope.component. Breaking that assumption allows multiple BFG apps to run in the same process, with incompatible components registered, without any chance that they will step on each other's toes. There is something similar, z3c.baseregistry, or not? -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: True love is when your heart and your mind are saying the same thing. - Leanna L. Bartram ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
On Mon, Feb 09, 2009 at 07:28:11AM -0800, Stephan Richter wrote: On Monday 09 February 2009, Brian Sutherland wrote: Oh, also, I guess it should use z3c.ptcompat rather than z3c.pt.compat for z3c.pt thing. I have a branch for that, but am blocked on merging that because the z3c.ptcompat code has test failures (in itself and z3c.form). These test failures existed before I moved z3c.pt.compat to z3c.ptcompat. Check it in; it will save Dan some time. ;-) Merged in 96320. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.form 2.0
So here's a little review on current status of z3c.form. Mostly based on items from CHANGES.txt for 2.0 release :) I may forget something, so I'll reply to myself if something suddenly comes in my mind. And sorry for my English, i'm quite in hurry now. :-) FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box. TextLinesWidget - Works. I've fixed a case when a field has tuple in its _type, so it hopefully will work in any case now. MultiWidget - Probably needs some review as it does the updateWidgets thing on value property setting, which seems fishy to me. It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt. ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status. Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources. However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility. z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this). Tests - All are passing. However there was a failure with z3c.pt, I've described before. I don't know what's wrong there, but found a little workaround. See my comment in the tests/simple_groupedit.pt file. (UPDATE: tests are now borked again as a result of merging z3c.ptcompat branch while I was writing this). Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now :) Also, I wanted to add browser widget attributes like klass or onclick to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's update method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release. One more thing I'd like to do is to add klass and id to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] opensp...@pycon 2009 about Zope/Repoze/Grok/Deliverence etc.
Lennart Regebro wrote: So, I propose to have an Open Space session at PyCon, Chicago, March 27-29 . Sounds good. Count me in. Hanno P.S. Yes, I'm at PyCon this year ;) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] opensp...@pycon 2009 about Zope/Repoze/Grok/Deliverence etc.
On Feb 9, 2009, at 12:03 PM, Lennart Regebro wrote: Lots of things have happened in the Zope universe the last couple of years, and are still happening, some of which are turning Zope inside out, from a monolithic ghetto to a componentized agile speed monster. People outside the Zope world doesn't know about it, and although the Zope community mostly seems to be on the same page, I think it would be nice if we get as many as possible together to discuss the status and where things are going. And, if we don't have anything to discuss, we can drop off to some bar and toast at how great Zope is. :-) So, I propose to have an Open Space session at PyCon, Chicago, March 27-29 . As this is a part of the unconference bit of PyCon, you don't have to sign up, but you can say if you are coming here anyway, just so we get a feeling for the interest. And although we can't decide when to do this yet, if you are only able to go to PyCon certain days, say so here, so we'll know when we can get the most participants. I'm supposed to be at PyCon, but I haven't seen the confirmation yet. If I'm there, sounds good. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] opensp...@pycon 2009 about Zope/Repoze/Grok/Deliverence etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09.02.2009 20:18 Uhr, Hanno Schlichting wrote: Lennart Regebro wrote: So, I propose to have an Open Space session at PyCon, Chicago, March 27-29 . Sounds good. Count me in. Will be there as well. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmQgvQACgkQCJIWIbr9KYziswCeMQmcFeP6trsN0x/wjL4nSTot WGoAoL19vpFkEYQf6ou1oGp5CcwffVgC =2s7/ -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Translations for zope packages.
Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. The zope.i18n = 3.5.0 have a feature of merging multiple message catalogs registered for the same domain. So we have two options here: a) Continue use the zope translation domain for all packages and make each package provide own message catalog to be merged into zope domain. b) Make every package provide its own translation domain. So say zope.container will have and register its own domain named zope.container. Either option is fine with me, however b) helps to avoid msgid clashes, whle a) allows us to reuse msgids. I'd like to hear community opinion on that and after we decide which option to choose I volunteer to migrate current zope.app.locales translations to every egg that have msgids, previously translated by zope.app.locales. However, that's kinda pain in the ass and I'll gladly accept any help on that. :-) -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0
On Monday 09 February 2009, Dan Korostelev wrote: FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box. Since this feature has not been there before, I can live without it for the 2.0 release. MultiWidget - Probably needs some review as it does the updateWidgets thing on value property setting, which seems fishy to me. Me too. :-) Roger, could you comment on this? Or Adam? It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt. Nice to have, but not necessary. ;-) ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status. Adam? I'll note that we use that code heavily at Keas, so at least for that limited exposure it seems fine. Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources. That's great to hear. However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility. Yeah, let's fix that. z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this). Malthe, do you have some time to look into this? Tests - All are passing. Clearly, all testsshould be passing. In addition, I would really like to see 100% test coverage after taking the false positives into consideration. Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now If translations are not updated until the next release, 2.1.0 or 2.0.1, that's fine with me. Also, I wanted to add browser widget attributes like klass or onclick to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's update method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release. One more thing I'd like to do is to add klass and id to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though. All nice to have. :-) I would not block the release because of it. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Translations for zope packages.
On Monday 09 February 2009, Dan Korostelev wrote: Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business. So basically, option (b) with option (a) as translation memory. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Planning for Zope 3.5
2009/2/9 Tres Seaver tsea...@palladion.com: I would rather move the Twisted support out into a non-core package, and focus on making the Zope3 components play nicely with *any* WSGI-compliant server. The fact that we still have a forked Twisted in Zope3 is directly tied to the absence of a crucial component in the released version of Twisted. Well, it's already not so bad. The zope.app.twisted is not the core package, and the zope.app.wsgi makes it easy to get the WSGI application of Zope. I've also just checked in an app_factory for PasteDeploy for it, so it can be used as an application component in the PasteDeploy pipeline without any additional python code. The zope.publisher also provides a simple WSGI application for use with paste. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Translations for zope packages.
2009/2/10 Stephan Richter srich...@cosmos.phy.tufts.edu: On Monday 09 February 2009, Dan Korostelev wrote: Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business. So basically, option (b) with option (a) as translation memory. Can you explain that once more? Do you mean that we translate each package in its own translation domain and then collect messages from all packages to a global translation domain that is used only as a translation memory and not for actual i18n of components? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0
2009/2/10 Stephan Richter srich...@cosmos.phy.tufts.edu: On Monday 09 February 2009, Dan Korostelev wrote: FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box. Since this feature has not been there before, I can live without it for the 2.0 release. Well, if that will be the only issue left, I'm personally also fine with releasing without it :)) However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility. Yeah, let's fix that. I'll check that. Tests - All are passing. Clearly, all testsshould be passing. In addition, I would really like to see 100% test coverage after taking the false positives into consideration. Ok, the fix for the z3c.ptcompat merge break was to provide a zope.testing.doctest as a doctest module for testing.OutputChecker, so all tests pass again. They are also mostly 100% covered. Most uncovered bits are in the ObjectWidget, MultiWidget and its combination. So those modules defenitely need a review. :-) If translations are not updated until the next release, 2.1.0 or 2.0.1, that's fine with me. Well, that's actually fine with me as well (as I've already updated my translation :-P), so that was a call for people who wants to get their translations ready for 2.0.0. One more thing I'd like to do is to add klass and id to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though. All nice to have. :-) I would not block the release because of it. That's fine with me to do that for the next release. BTW, I just discovered that forms have the id attribute, but it really points to the name which is a read-only property based on prefix, so they are not customizable at all. Was that done on purpose? I'd just set those attributes in the `update` method of the form. What do you think? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Translations for zope packages.
Hello Dan, In short, a good translation is consistent. That means the same sentences are translated to the same foreign sentence. A so-called translation memory is used for that. Also terms (specific words or expressions of the domain) are translated to the same foreign term. I think that's the idea of Stephan. There are proprietary tools to enforce this. I think launchpad translation is somehow also a translation memory as it pulls in previous translations. Though no idea how the above could be solved with FOSS tools. Tuesday, February 10, 2009, 2:36:28 AM, you wrote: DK 2009/2/10 Stephan Richter srich...@cosmos.phy.tufts.edu: On Monday 09 February 2009, Dan Korostelev wrote: Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business. So basically, option (b) with option (a) as translation memory. DK Can you explain that once more? Do you mean that we translate each DK package in its own translation domain and then collect messages from DK all packages to a global translation domain that is used only as a DK translation memory and not for actual i18n of components? -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: She is descended from a long line that her mother listened to. - Gypsy Rose Lee ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
