I have a version of zope.schema.Orderable (in
zope.schema._bootstrapfields.py) that passes additional tests having to
do with combination of missing_value with other constraints. (Released
version fails these.)
What should I do with it? I am new, and haven't contributed anything
before. Does
It would seem that the current default mechanism is poorly
suited to providing default values for non-immutables.
For example:
class IBar( Interface ):
a =
Object( schema = IFoo,
default = Foo() )
But if a Foo is not
immutable this doesnt make sense. (In my case, I want a to
be
ones? Seems like this is generally useful for
introspection of metadata.
-Original Message-
From: Shane Hathaway [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 12:39 PM
To: Shaun Cutts
Cc: zope3-dev@zope.org
Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables
-Original Message-
From: Stephan Richter [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 05, 2006 4:40 PM
To: zope3-dev@zope.org
Cc: Gary Poster; Shaun Cutts
Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables...
questions
On Sunday 05 February 2006 14:42, Gary Poster wrote
elsewhere easier.
-Original Message-
From: Stephan Richter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 5:15 AM
To: zope3-dev@zope.org
Cc: Shaun Cutts
Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables...
questions
On Monday 06 February 2006 11:53, Shaun Cutts wrote
Hello,
Im new here.. almost certainly these comments are off-base then
again, sometimes an idea from outside can be helpful. So heres
a crazy thought before I go to bed.
I wonder if the configuration done by zcml
might not be better if it resided inside a ZODB, and was manipulable
at
Martin,
Here here! I'm just learning to cross the gap starting from the RDBMS
side. Just our initial deployment will have a DB growing by about 30K
numbers per day, day in and day out. There are various workflows that
are driven by this data. The parts of these that need people are now
supposed
Max M wrote:
The problem is that all the people used to LAMP will come to Zope
and
think Well I will need to think differently here. Thats a bother. I
will use sql for everything like usual. And so we will get a lot of
duplicated efforts and half-baked Zope developers, who will
So my plea is: If we're going to have more than one way to do it,
let's please not invent lots of special magical things that
just work in one mode of development and have to be laboriously
rewritten in the other mode of development. It makes the border
between modes of working too hard to
It seems to me that some of the tension around zcml arises because, on
the one hand, everyone wants it to be as simple as possible, and on the
other, too much simplicity of the language makes some things very
tedious, which encourages magic shortcuts via new directives.
To let out some of the
One thing I havent got my mind around yet:
I notice that zodb is fairly
active about calling __getstate__ and __setstate__.
When a container gets pickled to be put into zodb, what happens to the subtree? Is it just left as a big
clump of stuff for the garbage collector to deal with?
Ok everyone: it is a zope bug.
The following should be included in zope.app.schema.fields.zcml:
content class=zope.schema.Date
factory
id=zope.schema.Date
title=Date Field
description=Date Field /
require like_class=zope.schema.Orderable /
require
Could we call it obfuscate instead, so we know what it does? :-)
I take it that's a no vote from you :)
But I think it can be sensibly used. There are many places in the zcml
defs where there are long blocks of repetitive definitions where only a
few names change. If the number of directives is
Chris,
-Original Message-
From: Chris Withers [mailto:[EMAIL PROTECTED]
Shaun Cutts wrote:
When a container gets pickled to be put into zodb, what happens to
the
subtree?
If the container has references to stuff that is contains, one of two
things could happen:
1
Chris,
You need to get into the habbit of CC'ing in the list you're replying
too...
Sorry -- I was thinking that, if this was not a problem w/ ZODB and
external objects, but I've missed something in implementation, maybe I
should have been communicating on Zope3-users instead. Now I don't know
Opps,
The code I said would be attached...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:zope3-dev-
[EMAIL PROTECTED] On Behalf Of Shaun Cutts
Sent: Friday, February 24, 2006 10:18 PM
To: 'Chris Withers'; [EMAIL PROTECTED]; 'zope3-dev'
Subject: RE: [Zope3-dev] zodb
Is there any reason why zope.app.form.browser.widget.DisplayWidget
doesnt implement zope.app.form.interfaces.IDisplayWidget,
or is this a bug?
- Shaun
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
17 matches
Mail list logo
