Re: [Zope-CMF] Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-10 Thread Leonardo Rochael Almeida
On Fri, 2003-10-10 at 14:34, Dieter Maurer wrote: > If such a "_v_" attribute is flushed, the next access to the DA > (in the same request) reopens the database. As this is a new > connection, it does not see the changes made by the previous > connection (in the same request). > > This can lead to

Re: [Zope-dev] relations in objects

2003-10-10 Thread Dieter Maurer
Jason Corbett wrote at 2003-10-9 20:46 -0700: > ... > How does an object in zope know where it sits in the > hirearchy, and how does it reach other objects. In fact, the object does not know it. In Zope, you usually do not deal with the object itself but with an acquisition wrapper. This wrap

Re: [Zope-CMF] Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-10 Thread Dieter Maurer
Casey Duncan wrote at 2003-10-10 09:26 -0400: > ... > IMO YAGNI. I think the application should tolerate the disappearance of > _v_ vars. I would consider the problem with CMF skins a bug that needs > to be fixed. AFAIK there is nothing stored in _v_skindata that cannot be > reconstructed f

Re: [Zope-CMF] Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-10 Thread Dieter Maurer
Toby Dickenson wrote at 2003-10-10 07:54 +0100: > ... > A while ago there was a discussion on zodb-dev about _v_-like attributes that > would be automatically cleared at the end of a transaction. Do we need > something similar that guarantees it will _not_ be cleared until the end of > the

RE: [Zope-dev] relations in objects

2003-10-10 Thread Simon Pamies
Hi Jason, if you want to deal with references and unique ids and that stuff, feel free to take a look at http://plone.org/development/current/projects/Ticle and perhaps to contribute your ideas or even sourcecode. -sp ___ Zope-Dev maillist - [EMAIL

Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-10 Thread Casey Duncan
Toby Dickenson wrote: On Thursday 09 October 2003 14:01, Florent Guillaume wrote: I agree with this. How do we go about find code that uses the assumption that _v_ stuff won't change unless it's at a transaction boundary? Note that we had a problem related to this with a client recently: In CMF,

RE: [Zope-dev] relations in objects

2003-10-10 Thread Tres Seaver
On Fri, 2003-10-10 at 05:51, Bjorn Stabell wrote: > > From: Paul Winkler [mailto:[EMAIL PROTECTED] > >> On Thu, Oct 09, 2003 at 08:46:24PM -0700, Jason Corbett wrote: > >> How does an object in zope know where it sits in the hirearchy, > > > > The only unique identifier that zope provides is > >

RE: [Zope-dev] relations in objects

2003-10-10 Thread Bjorn Stabell
> From: Paul Winkler [mailto:[EMAIL PROTECTED] >> On Thu, Oct 09, 2003 at 08:46:24PM -0700, Jason Corbett wrote: >> How does an object in zope know where it sits in the hirearchy, > > The only unique identifier that zope provides is > the containment path. An object can tell you its containment

Re: [Zope-dev] relations in objects

2003-10-10 Thread Paul Winkler
On Thu, Oct 09, 2003 at 08:46:24PM -0700, Jason Corbett wrote: > Thanks for your reply. I've actually been thinking in > an object oriented form for a while. I've looked at > implimenting this project in Java using either > prevailance or a object persistence model that mapped > to a RDBMS. I li