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, skin data is
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 like
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
the
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,
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 -
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 from
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
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 very
