Re: [Zope-dev] [Checkins] SVN: z3c.form/trunk/ merged branch icemac_validate_NOT_CHANGED
Hello Michael, After some simple thinking there are some fears that this wrecks other basic fields validation. Something like the field is required, has a default value but is omitted on input. What will be the result? Accepting the default value instead of raising an error is definitely a problem. Also, values in the system might not be needed to re-validate? Image passing around a 100mb uploaded file. If this is meant only for a file upload field, then I think there should be a special validator registered for those. Would be nice to see some (functional) tests closing out the above fears. Functional, because on the unittest level you can force the widget to a lot of unexpected things, but that might not be inline with what happens when it's really done by the framework. Or better said, revert the changes locally, add those tests, apply the changes back and see whether the tests still pass. Sunday, May 17, 2009, 3:21:19 PM, you wrote: MH> Log message for revision 100028: MH> merged branch icemac_validate_NOT_CHANGED MH> MH> Changed: MH> U z3c.form/trunk/AUTHOR.txt MH> U z3c.form/trunk/CHANGES.txt MH> U z3c.form/trunk/src/z3c/form/validator.py MH> U z3c.form/trunk/src/z3c/form/validator.txt MH> -=- MH> Modified: z3c.form/trunk/AUTHOR.txt MH> === MH> --- z3c.form/trunk/AUTHOR.txt 2009-05-17 13:18:11 UTC (rev 100027) MH> +++ z3c.form/trunk/AUTHOR.txt 2009-05-17 13:21:18 UTC (rev 100028) MH> @@ -11,10 +11,11 @@ MH> Daniel Nouri MH> Darryl Cousins MH> Herman Himmelbauer MH> +Jacob Holm MH> Laurent Mignon MH> Malthe Borch MH> Marius Gedminas MH> Martijn Faassen MH> Michael Howitz MH> Michael Kerrin MH> -Paul Carduner MH> +Paul Carduner MH> \ No newline at end of file MH> Modified: z3c.form/trunk/CHANGES.txt MH> === MH> --- z3c.form/trunk/CHANGES.txt 2009-05-17 13:18:11 UTC (rev 100027) MH> +++ z3c.form/trunk/CHANGES.txt 2009-05-17 13:21:18 UTC (rev 100028) MH> @@ -150,7 +150,11 @@ MH> MH> - Bug: Don't cause warnings in Python 2.6. MH> MH> +- Bug: `validator.SimpleFieldValidator` is now able to handle MH> + `interfaces.NOT_CHANGED`. This value is set for file uploads when MH> + the user does not choose a file for upload. MH> MH> + MH> Version 1.9.0 (2008-08-26) MH> -- MH> MH> Modified: z3c.form/trunk/src/z3c/form/validator.py MH> === MH> --- z3c.form/trunk/src/z3c/form/validator.py2009-05-17 13:18:11 UTC (rev 100027) MH> +++ z3c.form/trunk/src/z3c/form/validator.py2009-05-17 13:21:18 UTC (rev 100028) MH> @@ -42,9 +42,28 @@ MH> MH> def validate(self, value): MH> """See interfaces.IValidator""" MH> +context = self.context MH> field = self.field MH> -if self.context is not None: MH> -field = field.bind(self.context) MH> +widget = self.widget MH> +if context is not None: MH> +field = field.bind(context) MH> +if value is interfaces.NOT_CHANGED: MH> +if (interfaces.IContextAware.providedBy(widget) and MH> +not widget.ignoreContext): MH> +# get value from context MH> +value = zope.component.getMultiAdapter( MH> +(context, field), MH> +interfaces.IDataManager).query() MH> +else: MH> +value = interfaces.NO_VALUE MH> +if value is interfaces.NO_VALUE: MH> +# look up default value MH> +value = field.default MH> +adapter = zope.component.queryMultiAdapter( MH> +(context, self.request, self.view, field, widget), MH> +interfaces.IValue, name='default') MH> +if adapter: MH> +value = adapter.get() MH> return field.validate(value) MH> MH> def __repr__(self): MH> Modified: z3c.form/trunk/src/z3c/form/validator.txt MH> === MH> --- z3c.form/trunk/src/z3c/form/validator.txt 2009-05-17 13:18:11 UTC (rev 100027) MH> +++ z3c.form/trunk/src/z3c/form/validator.txt 2009-05-17 13:21:18 UTC (rev 100028) MH> @@ -117,7 +117,6 @@ MH> in the login name: MH> MH>>>> import re MH> - MH>>>> class LoginValidator(validator.SimpleFieldValidator): MH>... MH>... def validate(self, value): MH> @@ -182,7 +181,125 @@ MH>... (None, None, None, IPerson['email'], None), MH>... interfaces.IValidator) MH> MH> +Widget Validators and File-Uploads MH> +~~ MH> MH> +File-Uploads behave a bit different than the other form MH> +elements. Whether the user did not choose a file to upload MH> +``interfaces.NOT_CHANGED`` is set as value. But the validator knows MH> +how to handle this.
[Zope-dev] zc.buildout problem
Hello, Following just happened. The project has KGS 3.4 versions as a base, locally I wanted to override lxml to >= 2.1.1. [...snip...] extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg versions = versions [versions] lxml >= 2.1.1 [...snip...] The bin/buildout -v output was: Installing 'zc.buildout', 'setuptools'. We have the distribution that satisfies 'zc.buildout==1.1.1'. We have the distribution that satisfies 'setuptools==0.6c9'. [...snip...] Configuration data: [...snip...] [versions] [...snip...] lxml = 1.3.6 lxml > = 2.1.1 [...snip...] Getting required 'lxml==1.3.6' We have the distribution that satisfies 'lxml==1.3.6'. [...snip...] I thought the local [versions] would override the inherited ones? If I put lxml = 2.1.1 buildout nicely picks 2.1.1 Is this a bug? -- Best regards, Adam GROSZER mailto:agros...@gmail.com -- Quote of the day: Time is nature's way of making sure that everything doesn't happen at once. ___ 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 release?
Hello Malthe, Tiny problem is that the doctests seem to have the attributes in lxml-sane order. That means just by removing lxml output-sanitization even zpt output does not match the doctest. Also, lxml is used to do some xpath queries. Saturday, May 23, 2009, 10:23:16 AM, you wrote: MB> 2009/5/23 Adam GROSZER : >> The problem that I see here with lxml is that it is used for output >> checking. Even worse z3c.form requires at least 2.1.1 of lxml, where KGS >> 3.4 has lxml nailed at 1.3.6. MB> It might be possible to shed this testing dependency; ``lxml`` is used MB> because of its doctest-mode, but since then, Chameleon has been MB> equipped to render attributes in the ZPT order (instead of more or MB> less random). This was the raison d'etre to use lxml in tests. >> This burpes already on buildout. >> Now even if I would ignore this requirement for testing, (and testing) >> how could I be sure that tests pass (with KGS 3.4)? MB> Yes, I agree with that observation. MB> \malthe MB> ___ MB> Zope-Dev maillist - Zope-Dev@zope.org MB> http://mail.zope.org/mailman/listinfo/zope-dev MB> ** No cross posts or HTML encoding! ** MB> (Related lists - MB> http://mail.zope.org/mailman/listinfo/zope-announce MB> http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: What reason have atheists for saying that we cannot rise again? Which is more difficult: to be born, or to rise again? That what has never been should be, or that what has been should be again? Is it more difficult to come into being than to return to it? - Blaise Pascal ___ 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] zc.buildout problem
Adam GROSZER, on 2009-05-24: > Hello, > > Following just happened. The project has KGS 3.4 versions as a base, > locally I wanted to override lxml to >= 2.1.1. > > [...snip...] > extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg > versions = versions > > [versions] > lxml >= 2.1.1 Only assignment (=) is allowed here, not comparison (>=). Comparison is allowed in a few other spots, for example: recipe = my.recipe.name >= 1.0 -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] ___ 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] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Sat May 23 12:00:00 2009 UTC to Sun May 24 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat May 23 20:47:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011777.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat May 23 20:49:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011778.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Sat May 23 20:52:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011779.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sat May 23 20:54:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011780.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Sat May 23 20:56:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011781.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sat May 23 20:58:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011782.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sat May 23 21:00:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011783.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Sat May 23 21:02:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011784.html ___ 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] [action required] Zope Contributor Agreement change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Please exclude the mass-email, most of you will receive this more than once, we're hoping to catch any current contributor whose email address on zope.org is not current. Anyone who has svn.zope.org checkin privileges and has not received personal email with the content below, please read and follow the instructions, otherwise you may find yourself without access. Thanks! jens - --- You may be aware that the copyright for software stored in the software repositories on svn.zope.org has recently been assigned to the Zope Foundation, from the earlier copyright holder Zope Corporation. The old contributor agreements expressly assigned a joint copyright to Zope Corporation for any software checked into svn.zope.org repositories. With the Zope Foundation taking over these copyrights, the agreement with the contributors needs to change so that the Zope Foundation is the joint copyright holder for all new code coming into the repositories. For you as a contributor this means you need to submit a new contributor agreement[1] if you want to stay on as an active contributor to Zope and/or the other software hosted in the repositories on svn.zope.org. Here's how: - - download the new agreement[1] - - fill in the new agreement, and since you are a current contributor it is OK to enter Jim Fulton (j...@zope.com) as the required reference committer - - sign and date the agreement - - either scan the agreement and email it to foundation-i...@zope.org, or fax it to the Zope Foundation fax number +1 (703) 842-8076 To ensure a timely copyright transition we ask you to submit the new contributor agreement no later than June 17, 2009. The Zope Foundation board will try to contact any contributor who has not replied at that point between June 18 and June 26, and on June 26 checkin access will be removed for those who have not sent in the new agreement. Thanks again for your support! Jens Vagelpohl Secretary, Zope Foundation Board of Directors [1] http://foundation.zope.org/agreements/ZopeFoundation_Committer_Agreement -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoZOwkACgkQRAx5nvEhZLLfxwCglA45Oyk3fIr8uUasH5O4BQc9 VIEAnA2Tdk/Yh3C5bDlnIcaCklcQd/Ci =/wUA -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] zc.buildout problem
Maurits van Rees wrote: > Adam GROSZER, on 2009-05-24: >> Hello, >> >> Following just happened. The project has KGS 3.4 versions as a base, >> locally I wanted to override lxml to >= 2.1.1. >> >> [...snip...] >> extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg >> versions = versions >> >> [versions] >> lxml >= 2.1.1 > > Only assignment (=) is allowed here, not comparison (>=). Right. And note that it's =, not ==. A [versions] block is not a version spec, it's an explicit pin. You may also be interested in the buildout.dumppickedversions, which helps you analyse what buildout actually picked, and possibly in http://good-py.appspot.com, which helps you manage version pins in different "layers" for different platforms. For example, you could add a second line to 'extends' with another KGS layered on top of the Zope 3.4.0 one, overriding some versions and adding others. > Comparison is allowed in a few other spots, for example: > > recipe = my.recipe.name >= 1.0 And in any 'eggs' line. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] package dependency refactoring progress report
Hey, Shane Hathaway wrote: > Done. I look forward to seeing the changes in the dependency graph. Great, thanks! The only cycle left in the zope.app.publisher graph is between zope.container and zope.filerepresentation. The graph now contains 42 notes, so we got rid of 3 more dependencies. Here it is: http://startifact.com/depgraphs/zope.app.publisher-after2.svg It's interesting to see zope.deprecation is a new dependency. We could consider changing these deprecations to simple imports if this is possible... Knowing there are no cycles besides the zope.container one, this graph starts to look comprehensible, that's good. :) Here's zope.app.publication (same zope.container cycle, no other cycles); http://startifact.com/depgraphs/zope.app.publication.svg And here's zope.app.http: http://startifact.com/depgraphs/zope.app.http.svg (again the zope.container cycle, nothing else) 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 )
Re: [Zope-dev] package dependency refactoring progress report
Hi there, Shane Hathaway wrote: [snip] > Summarizing: > > zope.app.publisher -> zope.view > zope.app.publication -> zope.publicationregistry > zope.app.http -> zope.rest I'm not sure about zope.rest; there's already a z3c.rest which likely does something quite different, and I think a "zope.rest" package should actually *talk* about REST. What about "zope.httpview" instead? Another note, I think we should consider splitting off zope.app.publisher.xmlrpc, which looks quite independent from the rest, into its own package. So: zope.app.publisher -> zope.view, zope.xmlrpcview One question is whether zope.httpview and zope.xmlrpcview are really similar enough to warrant such a similar naming convention. zope.app.publisher.xmlrpc does not only define some XMLRPC-related views, it also defines a ZCML directive, which zope.httpview doesn't do. I also wonder what should happen with zope.publisher.xmlrpc (which also looks quite independent from the rest of the zope.publisher code). 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 )
