Fred Drake wrote:
On 7/7/05, Martijn Faassen [EMAIL PROTECTED] wrote:
I hope that moving it into the zope package doesn't mean it will be only
maintained for Zope 3.2 (as it requires python 2.4). While I obviously
don't expect it to be released with Zope 3.1 I hope we can pull a
release of it
Tres Seaver wrote:
[snip]
I find the same pattern creeping into my work: content objects need to
be policy free, which means that they can't do things like emit
events, because whether and when to emit them is policy. For
instance, if your content objects have setter methods (or properties as
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
Christian Theune wrote: [snip]
I'm actually interested in what the plans/needs for zc.page are to
move into core. Maybe I/we can spend some time on bug fixing ...
Even if not in the core, it'd already help if this wasn't a
Benji York [EMAIL PROTECTED] wrote:
Jim Fulton wrote:
We don't want to *require* objects to provide ILocation.
I don't know what the right answer is here. I'll think about it. I'd
love some good suggestions.
Perhaps an ILocation adapter that would keep the __name__ and __parent__
I'm having a hard time grasping the reasons why we have both
ILocation and IContained.
class IContained(ILocation):
Objects contained in containers.
But ILocation provides a __parent__ already, which seems to imply
that it's contained in it. No?
What use case makes us differentiate
[Dieter Maurer]
Restrictions are fine when they are either
* enforced (I know BTrees do not enforce the no mixed key types
restriction)
* clearly documented
I do not know whether the ZODB 3.4 BTrees interfaces document
the restriction (this would be a good place, I think)
I downloaded the zope3 package Zope-3.1.0b1.win32-py2.4.exe and installed
it.
but I don't know how to start it, anyone can help
newcomer
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
