[Zope3-dev] Add function for schema validation in zope.schema
Hi,
zope.schema defines how a schema can be validated, defines errors and
provides a way to validate single fields.
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
validateSchema(IMySchema, myobject) [or alike]
I'm not sure about return values or exceptions. There are different use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
Comments?
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: AW: relying on win32api in windows supportofzc.zope3recipes
On Friday 17 August 2007 17:32, Gary Poster wrote: However, it's worth noting to clarify this discussion that buildout is being successfully used to install a wide variety of software on *nix systems (I know of Red Hat, Ubuntu, and OS X). This includes software that does not have eggs (such as M2Crypto) and software that does not have much to do directly with Python (such as libxml2 and swig). Windows is pretty different in this respect. You really want to use an installer, which means you get a wizard. People in Windows expect this behavior and want it. It is quiet ignorant to ask them to use eggs instead. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
Hi,
Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use
cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
From my latest experience and research of when to use exceptions and
when to use return values I'd say let's not use an exception.
The report of which fields are wrong is the normal result of this
function. Invalid data is not an uncommon output, rather, it's the sole
purpose of this function. An exception should be raised if the
validation could not be performed.
The result could be a structure that lists all errors. Eventually a
result that equals False could be used to signal no errors, e.g. an
empty dict or an empty list.
Currently I suspect that a list as the result would be more useful, if
we do care for invariants. What about this:
[(Field xy, u'Invalid foo'),
(Invariant ab, u'Invalid bar')]
If the list is empty then there were no errors.
Christian
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
On 2007-08-20 14:59:52 +0200, Fred Drake [EMAIL PROTECTED] said:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
Yes, I like the idea.
Will add it with the exception as time comes by.
--
Christian Zagrodnick
gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
Christian Theune wrote: From my latest experience and research of when to use exceptions and when to use return values I'd say let's not use an exception. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
Previously Christian Theune wrote:
Hi,
Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use
cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
From my latest experience and research of when to use exceptions and
when to use return values I'd say let's not use an exception.
The report of which fields are wrong is the normal result of this
function. Invalid data is not an uncommon output, rather, it's the sole
purpose of this function. An exception should be raised if the
validation could not be performed.
The result could be a structure that lists all errors. Eventually a
result that equals False could be used to signal no errors, e.g. an
empty dict or an empty list.
That would be confusing though: I would expect the result of a method
that checks validaty to return something that evaluates to True if
everything is valid. Code like this just messes up my brain:
if not zope.schema.validate(obj, IMySchema):
print Everything validates correctly!
to me that is very non-intuitive and looks like the if condition is
incorrect.
Wichert.
--
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: AW: [Zope3-dev] Re: AW: relying on win32api in windows supportofzc.zope3recipes
Monday, August 20, 2007, 3:05:45 PM, Stephan Richter wrote: Windows is pretty different in this respect. You really want to use an installer, which means you get a wizard. People in Windows expect this behavior and want it. It is quiet ignorant to ask them to use eggs instead. Hackers on win32 can live with eggs, but beginners surely not. The wizard might be a simple wrapper around the scenes behind. Ask some parameters/path/anything, start the install script with python, provide some progress feedback. -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] browser:page's for= can be class browser:menuItem can't
Hoi I just figured, that the browser:menuItem cannot be registered for classes. But you can with browser:page. I think if a browser:page can be registered for a class a menuItem should support this, too. Also a browser:page for=someclass menu=... / will break on getting the menu items because the implementation doesn't support classes. Should we fix that? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
Wichert Akkerman wrote: That would be confusing though: I would expect the result of a method that checks validaty to return something that evaluates to True if everything is valid. Code like this just messes up my brain: if not zope.schema.validate(obj, IMySchema): print Everything validates correctly! to me that is very non-intuitive and looks like the if condition is incorrect. Agreed. I prefer to name boolean methods with an is prefix. Then we would have if zope.schema.isValid(obj, IMySchema): print 'valid' and if not zope.schema.isValid(...): print 'invalid' That doesn't give any information about what is invalid though, I'd use a separate method for that. Perhaps something like getValidationErrors. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: browser:page's for= can be class browser:menuItem can't
Christian Zagrodnick wrote: Hoi I just figured, that the browser:menuItem cannot be registered for classes. But you can with browser:page. I think if a browser:page can be registered for a class a menuItem should support this, too. Also a browser:page for=someclass menu=... / will break on getting the menu items because the implementation doesn't support classes. Should we fix that? Absolutely. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use
cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
- -1. Detecting the schema violation is mechanism, raising an
exception is policy; they shouldn't be mixed here. Let the caller
raise an exception if that is appropriate
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
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
iD8DBQFGyZ9V+gerLs4ltQ4RAvEkAJwKK50BjjTwzNE39gsw1nXXq+JNVACcDKWK
2jxn+16Ax1Lx2sXf6vAy2EM=
=Y25B
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
Christian Theune wrote:
Hi,
Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
From my latest experience and research of when to use exceptions and
when to use return values I'd say let's not use an exception.
The report of which fields are wrong is the normal result of this
function. Invalid data is not an uncommon output, rather, it's the sole
purpose of this function. An exception should be raised if the
validation could not be performed.
The result could be a structure that lists all errors. Eventually a
result that equals False could be used to signal no errors, e.g. an
empty dict or an empty list.
This is exactly what I would suggest: The function should return a list
of validation errors. Similar semantics are used in zope.formlib's
validate() method. I agree with Wichert's objection about being a bit
confusing, though. Perhaps a better name than validateSchema could
solve this problem, though I can't think of a good one right now...
getValidationErrors() seems to naive...
Having access to the original ValidationError exceptions (incl. the
field name that they were thrown for) is probably all the information
you're ever going to want (and get).
Currently I suspect that a list as the result would be more useful, if
we do care for invariants. What about this:
[(Field xy, u'Invalid foo'),
(Invariant ab, u'Invalid bar')]
If the list is empty then there were no errors.
--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
Previously Christian Theune wrote:
Hi,
Am Montag, den 20.08.2007, 08:59 -0400 schrieb Fred Drake:
On 8/20/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
I think we should add a function to validate a given schema on a given
class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
validateSchema(IMySchema, myobject) [or alike]
+1
I'm not sure about return values or exceptions. There are different use
cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
There should probably be a specific exception that's defined for this
purpose, and it could directly support the mapping interface to allow
detailed information to be extracted. I suspect a common use would be
to simply verify the object and raise the exception in the invalid
case, denying whatever operation was being attempted.
This also suggests that there's no interesting return value; either
the exception is raised or it isn't. Code that wants to introspect
the exception can catch that and act accordingly.
From my latest experience and research of when to use exceptions and
when to use return values I'd say let's not use an exception.
The report of which fields are wrong is the normal result of this
function. Invalid data is not an uncommon output, rather, it's the sole
purpose of this function. An exception should be raised if the
validation could not be performed.
The result could be a structure that lists all errors. Eventually a
result that equals False could be used to signal no errors, e.g. an
empty dict or an empty list.
That would be confusing though: I would expect the result of a method
that checks validaty to return something that evaluates to True if
everything is valid. Code like this just messes up my brain:
if not zope.schema.validate(obj, IMySchema):
print Everything validates correctly!
to me that is very non-intuitive and looks like the if condition is
incorrect.
Returning boolean discards the information which only this function
should know, and which the caller (potentially) needs: the list of
errors. The name 'validate' doesn't imply a boolean return to me at
all. I would expect to see it used as follows::
errors = zope.schema.validate(obj, IMySchema)
if not errors:
print 'OK
else:
print 'Errors: \n%s' % '\n'.join([str(x) for x in errors])
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
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
iD8DBQFGyaBB+gerLs4ltQ4RAjDQAJ9e1gY/MxrAF7dOpTcATtQPjLAQ7gCgqy4X
2QztzPecPxDIKEqfvJUr0AI=
=IxRz
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Add function for schema validation in zope.schema
Am Montag, den 20.08.2007, 16:05 +0200 schrieb Philipp von Weitershausen: This is exactly what I would suggest: The function should return a list of validation errors. Similar semantics are used in zope.formlib's validate() method. I agree with Wichert's objection about being a bit confusing, though. Perhaps a better name than validateSchema could solve this problem, though I can't think of a good one right now... getValidationErrors() seems to naive... Having access to the original ValidationError exceptions (incl. the field name that they were thrown for) is probably all the information you're ever going to want (and get). Right. The validation error objects are probably enough as they have enough context to retrieve the field or invariant for which they apply. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Add function for schema validation in zope.schema
On 20 Aug 2007, at 16:12 , Benji York wrote: Philipp von Weitershausen wrote: This is exactly what I would suggest: The function should return a list of validation errors. Similar semantics are used in zope.formlib's validate() method. I agree with Wichert's objection about being a bit confusing, though. Perhaps a better name than validateSchema could solve this problem, though I can't think of a good one right now... getValidationErrors() seems to naive... I feel myself slipping into a bikeshed, so this may be my last comment on this. I like getValidationErrors. It's use would probably normally look something like this: errors = getValidationErrors(...) if errors: ... or: errors = getValidationErrors(...) if not errors: ... Both look good to me. +1 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
On Aug 20, 2007, at 7:48 AM, Christian Zagrodnick wrote:
Hi,
zope.schema defines how a schema can be validated, defines errors
and provides a way to validate single fields.
I think we should add a function to validate a given schema on a
given class. This should include constraints and invariants:
validateSchema(IMySchema, myobject) [or alike]
I'm not sure about return values or exceptions. There are different
use cases:
1. Is the object valid? - True/False
2. What's wrong with the object - {attribute/field-name: what's
wrong}, what's wrong with invariants.
Comments?
I remember discussing this a year or more ago. I don't remember where.
I'd like to see this fit into the zope.interface.verify framework.
I'd like to see the verify module refactored to be pluggable and I'd
like to see schema versification plug into this. This would *also*
motivate (or at least enable) people to do better method verification
and possibly provide other kinds of verification.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] browser:page's for= can be class browser:menuItem can't
On Aug 20, 2007, at 9:45 AM, Christian Zagrodnick wrote: Hoi I just figured, that the browser:menuItem cannot be registered for classes. But you can with browser:page. I think if a browser:page can be registered for a class a menuItem should support this, too. Also a browser:page for=someclass menu=... / will break on getting the menu items because the implementation doesn't support classes. Should we fix that? Yes. Any time we have a for, we should allow interfaces or classes. BTW, you may soon discover what I discovered the other day, which is that the tiny menu framework used for zmi_views doesn't work with menu items registered for classes. Someone should fix that too. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: AW: relying on win32api in windows supportofzc.zope3recipes
Adam Groszer wrote: Monday, August 20, 2007, 3:05:45 PM, Stephan Richter wrote: Windows is pretty different in this respect. You really want to use an installer, which means you get a wizard. People in Windows expect this behavior and want it. It is quiet ignorant to ask them to use eggs instead. Hackers on win32 can live with eggs, but beginners surely not. The wizard might be a simple wrapper around the scenes behind. Ask some parameters/path/anything, start the install script with python, provide some progress feedback. We have to be careful in separating the audiences here. Anyone using a buildout is expected to be an experienced user, probably a developer. They might be a beginning developer, in which case I consider installing a buildout *easier* than any of the alternatives, as a buildout ensures the whole environment is set up and only requires Python to be installed (and possibly python windows extensions). For deploying to end users of applications, it would be nice if we had a way to turn a buildout for an application into a binary windows installer automatically. This is related to the work I hear ZC is doing to create rpms from buildouts. I'm not sure how frequently we expect people to install Zope 3 applications on Windows machines, so it depends on our priority as a community. I actually do have use cases for it, but I can live with buildouts. Automatic installers for applications also involve other issues to be worked out - you often want to be able to update an application to a newer version without losing the database, for instance. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: AW: relying on win32api in windows supportofzc.zope3recipes
Stephan Richter wrote: On Friday 17 August 2007 17:32, Gary Poster wrote: However, it's worth noting to clarify this discussion that buildout is being successfully used to install a wide variety of software on *nix systems (I know of Red Hat, Ubuntu, and OS X). This includes software that does not have eggs (such as M2Crypto) and software that does not have much to do directly with Python (such as libxml2 and swig). Windows is pretty different in this respect. You really want to use an installer, which means you get a wizard. People in Windows expect this behavior and want it. It is quiet ignorant to ask them to use eggs instead. Ignorant? Eggs have the binary versions for a reason, and one of the main reasons is actually Windows deployment. It would be nice if one could install Zope 3-based *applications* using a Windows installer. But to ask developers to install all the *library* dependencies separately using click-through wizards is rather strange. It's not like Windows users *enjoy*, say, when installing their hardware drivers, to click through literally 12 installers, many of them quite different, as I recently had to do on a computer. People in windows want installers for applications. We're not talking about installing a normal application, however. We're talking about installing a buildout, typically as a Python developer. We're talking about installing library dependencies. As to installing Python libraries, eggs and buildout now allow us to run the exact same buildout.cfg and make it work on Windows and *nix both. This is a valuable feature! You really have to separate the audiences here. When talking about buildout on windows, we're talking about developers or advanced users. They check these things out from SVN. When you mention automatic installers, that makes more sense for end-users. I can imagine a graphical tool to set up buildouts for developers on Windows, but I imagine that's more the task of some IDE than of an installer. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AW: Re: AW: relying on win32api in windows supportofzc.zope3recipes
Martijn Faassen wrote: It would be nice if one could install Zope 3-based *applications* using a Windows installer. But to ask developers to install all the *library* dependencies separately using click-through wizards is rather strange. As a recovering Windows developer, I agree. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZODB versions / and windows eggs
Hey, Thanks for noticing. I think we need to adopt a routine of building Windows eggs whenever we make a new release of a package that has C extensions. There aren't that many packages like that (about a dozen) and they hopefully aren't going to have that many releases in the future. I've built Windows eggs for the two you mention now using the MinGW compiler (nobody has objected to it so far, and I figure cheap-but-perhaps-slow eggs are better than none). They're up on the CheeseShop. Thanks for these newer versions. MinGW, btw, is real easy to install and has helped me getting the eggified Zope 3 finally working on Windows when there were no binary eggs on the CheeseShop yet. I'm worried about mixing eggs built with different systems. How is Jim building his eggs? With Visual Studio? How solid are MinGW eggs? Should we really rely on this infrastructure or do we prefer to use Visual Studio as a community? As far as I understand the Python interpreter is constructed with a particular version of Visual Studio. It might be wise to ask someone with experience with Python development on the windows platform before we commit to one way or another. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: AW: relying on win32api in windows supportofzc.zope3recipes
Benji York wrote: Martijn Faassen wrote: It would be nice if one could install Zope 3-based *applications* using a Windows installer. But to ask developers to install all the *library* dependencies separately using click-through wizards is rather strange. As a recovering Windows developer, I agree. Another point is that Stephan makes it seem as if eggs are some *nixy thing that Windows developers don't know about. I just realize that's rather funny, as developers on Linux for example also tend to complain about eggs as they don't work with their normal distribution's package management system. All of this ignores that both Windows installers and the distribution package management system are not generally used to set up development environments. That is, it could be used to set up part of a development environment - stable tools, and libraries with APIs that don't change rapidly. But often a development project needs to rely on newer versions of libraries, and frequently even has to dive into the library and change it. This is where a buildout environment fits in. It's not the normal way of doing things on any platform though. That's because buildout is primarily a development tool, which hopefully in the future will grow more facilities to make deployment (as Windows installer, .deb package, or whatever) really easy as well. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Heads up: major change in zc.buildout policy for selecting distributions
I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Heads up: major change in zc.buildout policy for selecting distributions
Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. Yay! -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZODB versions / and windows eggs
Hey, On 8/20/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: On 20 Aug 2007, at 18:48 , Martijn Faassen wrote: [snip] How solid are MinGW eggs? So far nobody can tell me, except that Andreas Jung, Hanno Schlichting and a couple of other guys seem to be able to use MinGW well. That is good news! [snip] It might be wise to ask someone with experience with Python development on the windows platform before we commit to one way or another. Sure. I wasn't trying to commit to anything, I was just trying to fix a problem for myself in an inexpensive and convenient way. If somebody donated a VS license, heck, I'll take it :). My apologies, I wasn't suggesting you were forcing anything on the community, just recognized that we need to take an active decision here. Seriously, it would be cool if we could build Windows/Visual Studio eggs in an automated way. Surely buildbot could be used for this, if somebody would make a machine with VS installed available as a slave... Right, MinGW has a massive advantage here and unless we get some serious VS help I think we may have to go this way, as doing so will distribute our ability to build windows eggs much more than the VS way. It all depends on how well MinGW eggs work in practice, however. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false How will this be versioned? It'd be helpful if it were a different major (or at least minor) version than the current one, to make it easier for people to stick with a version that has the policy they normally use. Other than that, +1 for this policy change. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
On Aug 20, 2007, at 2:02 PM, Martin Aspeli wrote: Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non- final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false How will this be versioned? It is 1.0.0b29. (The buildout version numbers are a bit of a mess, as I was overoptimistic when I made the initial beta release. Hm, maybe I should start using es. These could be eek release. ;) It'd be helpful if it were a different major (or at least minor) version than the current one, to make it easier for people to stick with a version that has the policy they normally use. Maybe I should have, but the release is out of the barn. If this ends up causing too much pain, I could back this out by making a b30 release with the old policy, although, I'd rather not. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
On Aug 20, 2007, at 2:18 PM, Jim Fulton wrote: On Aug 20, 2007, at 2:02 PM, Martin Aspeli wrote: Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false How will this be versioned? It is 1.0.0b29. (The buildout version numbers are a bit of a mess, as I was overoptimistic when I made the initial beta release. Hm, maybe I should start using es. These could be eek release. ;) It'd be helpful if it were a different major (or at least minor) version than the current one, to make it easier for people to stick with a version that has the policy they normally use. Maybe I should have, but the release is out of the barn. If this ends up causing too much pain, I could back this out by making a b30 release with the old policy, although, I'd rather not. No, I'm wrong, I'm going to back these changes out with a b30 release and then release them with a 2x release. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
Am Montag, den 20.08.2007, 14:27 -0400 schrieb Jim Fulton: No, I'm wrong, I'm going to back these changes out with a b30 release and then release them with a 2x release. Will the 2x release be picked up automatically because the stable policy isn't in 1x and it tries to update itself? Oh wait, I might get stuck with b29 until 1.0 comes out which in turn will prefer 2x. Huh? :) Anyway: Yay for 1.0! Yay for preferring stable releases! Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
On Aug 20, 2007, at 1:18 PM, Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non- final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false I decided, with some prompting from Martin Aspeli, that this would be too disruptive. The latest release of zc.buildout still supports newest releases. To prefer final releases, you have to set the prefer-final option to true. In zc.buildout version 2, final releases will be prefered by default. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] browser:page's for= can be class browser:menuItem can't
On Monday 20 August 2007 09:45, Christian Zagrodnick wrote: Should we fix that? Yes, or just deprecate the menu stuff. ;-) The default menu framework was insufficient in every real-world project I have worked on. Menu items based on the context just do not work. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] browser:page's for= can be class browser:menuItem can't
On Monday 20 August 2007 20:02, Jim Fulton wrote: On Aug 20, 2007, at 7:57 PM, Stephan Richter wrote: On Monday 20 August 2007 09:45, Christian Zagrodnick wrote: Should we fix that? Yes, or just deprecate the menu stuff. ;-) The default menu framework was insufficient in every real-world project I have worked on. Menu items based on the context just do not work. They don't? I have certainly found them useful in the ZMI. As bad as the ZMI is for many apps, I find it very useful as a default UI and for groveling around in site component registries. I think this is a very limited use case. In real applications you often have the concept of global menus. Further, often I want to make a menu item part of the menu of a particular object, but I left the actual context, for example by traversing to an attribute of that object. Overall I have found viewlets and the menu system we have built on top of them to be much more flexible and they have accommodated all my use cases. Also, they are somewhat more efficient in terms of look-up. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Add function for schema validation in zope.schema
On 8/20/07, Benji York [EMAIL PROTECTED] wrote: I like getValidationErrors. It's use would probably normally look something like this: ... Both look good to me. Ok, agreed, for reasons people have already given. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
