Re: [Zope-dev] The Application object
Yves-Eric Martin wrote: > > Shane Hathaway <[EMAIL PROTECTED]> wrote: > > You *must* remember to close the connection: > > > > app._p_jar.close() > > This is not mentionned in the above document, so I was doing without > so far, and did not run into any problem. Now that I see it, I believe > this is the Right Thing to Do and will include it in the release. But > since you put an emphasis on its being required, can you tell us what > evil things may happen if you don't close the connection? (Consuming > ressources?) That's correct. Only a certain number of connections are allowed at a time. Currently, as the "app" object falls out of scope it should close the connection automatically, but that may not always be the case IMHO. BTW if you're using this technique, be sure you're not opening two connections in one thread. It can prove hazardous. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
On Mon, 17 Jul 2000 12:50:27 -0400 Shane Hathaway <[EMAIL PROTECTED]> wrote: > import Zope > app = Zope.app() > > get_transaction().commit() I am doing just that in the next version of zzLocale (Zope interface internationalization product) I was about to release. I figured it out >from the "Zope Debugging" doc (http://www.zope.org/Documentation/Misc/DEBUGGING.txt), but: > You *must* remember to close the connection: > > app._p_jar.close() This is not mentionned in the above document, so I was doing without so far, and did not run into any problem. Now that I see it, I believe this is the Right Thing to Do and will include it in the release. But since you put an emphasis on its being required, can you tell us what evil things may happen if you don't close the connection? (Consuming ressources?) -- Yves-Eric Martin Digital Garage Inc. [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
On Mon, Jul 17, 2000 at 12:21:42PM -0400, Jeff K. Hoffman wrote:
> On Mon, 17 Jul 2000, Chris McDonough wrote:
>
> > I'm not sure I understand. What is AppSingleton? What does the
> > Instance() method do?
>
> Sorry I wasn't clear enough. The Singleton is a design pattern from the
> Gang of Four book that fits this situation well. It is a class that is
> meant to control access to the one and only instance of a global
> variable. I was just using that as a frame of reference, though; Zope has
> no such class for the Application object, or I wouldn't be writing this
> message.
>
> I just need some way of getting at the one and only Application object at
> run-time. Something like:
>
> from Globals import app
> myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
> ...
>
> Given a reference to an object in the ZODB, I can do this via:
>
> app = self.getPhysicalRoot()
> myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
>
> But, this does not work from methods like __init__, or __setstate__, where
> we do not have a physical location in the ZODB, yet.
>
> I just need a reference to the app object. I know the answer has to be
> simple, but I can't find it.
See the __init__.py method of ZScheduler, which can be found on Zope.org.
ZScheduler uses a Singleton as well.
--
Martijn Pieters
| Software Engineermailto:[EMAIL PROTECTED]
| Digital Creations http://www.digicool.com/
| Creators of Zope http://www.zope.org/
| ZopeStudio: http://www.zope.org/Products/ZopeStudio
-
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
On Mon, 17 Jul 2000, Chris McDonough wrote:
> How about a class attribute?
>
> class MyClass:
>
> myAttr2 = 'Default'
>
> def getMyAttr1(self):
> return self.myAttr1
>
> def getMyAttr2(self):
> return self.myAttr2
>
> If myAttr2 needs to be a ZClass instance, just grab it inside the class.
Again, it comes down to instantiation. I would need:
class MyClass:
myAttr2 = app.Control_Panel.Products.MyProduct.MyZClass('id')
and we're back to not having app, again.
Also, myAttr2 is volatile. Each instance of MyClass should have its own
instance of myAttr2; a class attribute would not give the desired
semantics.
I wish it were that easy.
Thanks,
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
How about a class attribute? class MyClass: myAttr2 = 'Default' def getMyAttr1(self): return self.myAttr1 def getMyAttr2(self): return self.myAttr2 If myAttr2 needs to be a ZClass instance, just grab it inside the class. > -Original Message- > From: Jeff K. Hoffman [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 17, 2000 2:44 PM > To: Chris McDonough > Cc: 'Jeff K. Hoffman'; Shane Hathaway; [EMAIL PROTECTED] > Subject: RE: [Zope-dev] The Application object > > > On Mon, 17 Jul 2000, Chris McDonough wrote: > > > Jeff, what exactly do you need to do with setstate? can > you provide an > > example? > > I am simply trying to "upgrade" a persistent instance of a > Python class. > For instance: > > class MyClass: > > def __init__(self, id, title=''): > self.myAttr1 = 'Value 1' > > def getMyAttr1(self): > return self.myAttr1 > > Imagine that I use the class, as defined above, for a while, then > decide I need to modify it as follows: > > class MyClass: > > def __init__(self, id, title=''): > self.myAttr1 = 'Value 1' > self.myAttr2 = 'Value 2' > > def getMyAttr1(self): > return self.myAttr1 > > def getMyAttr2(self): > return self.myAttr2 > > I already have a few instances of MyClass in the ZODB, and > they only have > myAttr1; myAttr2 is not defined on existing instances, since > they will not > be constructed via the new __init__. Therefore, getMyAttr2() > will throw an > exception. > > The simple solution is to also define __setstate__: > > def __setstate__(self, state): > Persistent.__setstate__(self, state) > if not hasattr(self, 'myAttr2'): > self.myAttr2 = 'Value 2' > > Now, when the old instances of my object are de-ghosted from the ZODB, > __setstate__ notices that they don't have a myAttr2, and sets > it to the > value normally given by the constructor. > > Unfortunately, in my case, 'Value 2' is an instance of a ZClass. > Therefore, I need to get at Control_Panel. > > Hope this helps. Now I'm going to try Shane's wacky __of__ idea. :-) > > --Jeff > > --- > Jeff K. Hoffman 704.849.0731 x108 > Chief Technology Officer mailto:[EMAIL PROTECTED] Going Virtual, L.L.C. http://www.goingv.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
On Mon, 17 Jul 2000, Chris McDonough wrote: > Jeff, what exactly do you need to do with setstate? can you provide an > example? I am simply trying to "upgrade" a persistent instance of a Python class. For instance: class MyClass: def __init__(self, id, title=''): self.myAttr1 = 'Value 1' def getMyAttr1(self): return self.myAttr1 Imagine that I use the class, as defined above, for a while, then decide I need to modify it as follows: class MyClass: def __init__(self, id, title=''): self.myAttr1 = 'Value 1' self.myAttr2 = 'Value 2' def getMyAttr1(self): return self.myAttr1 def getMyAttr2(self): return self.myAttr2 I already have a few instances of MyClass in the ZODB, and they only have myAttr1; myAttr2 is not defined on existing instances, since they will not be constructed via the new __init__. Therefore, getMyAttr2() will throw an exception. The simple solution is to also define __setstate__: def __setstate__(self, state): Persistent.__setstate__(self, state) if not hasattr(self, 'myAttr2'): self.myAttr2 = 'Value 2' Now, when the old instances of my object are de-ghosted from the ZODB, __setstate__ notices that they don't have a myAttr2, and sets it to the value normally given by the constructor. Unfortunately, in my case, 'Value 2' is an instance of a ZClass. Therefore, I need to get at Control_Panel. Hope this helps. Now I'm going to try Shane's wacky __of__ idea. :-) --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:[EMAIL PROTECTED] Going Virtual, L.L.C. http://www.goingv.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
"Jeff K. Hoffman" wrote:
> All of my efforts are progressing towards one goal: How do I upgrade
> existing instances of a ZClass? Since I could find no __setstate__ method
> for ZClasses, I re-wrote the containing class as a Python class and
> figured I could leverage __setstate__ there, instantiating the subordinate
> ZClasses when required.
>
> No such luck.
Okay, here's an interesting approach. I've been playing with __of__ a
lot lately, so why not see what else it can do? :-)
In your class that needs to be upgraded, add this method, modifying it
as needed:
def __of__(self, parent):
if (self.isNotUpgraded()):
self.performUpgrade()
return MyClass.inheritedAttribute('__of__')(self, parent)
When any user walks up to the object, you will have the opportunity to
perform the upgrade.
Shane
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
Jeff, what exactly do you need to do with setstate? can you provide an
example?
> -Original Message-
> From: Jeff K. Hoffman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 17, 2000 1:49 PM
> To: Shane Hathaway
> Cc: Jeff K. Hoffman; Chris McDonough; [EMAIL PROTECTED]
> Subject: Re: [Zope-dev] The Application object
>
>
> On Mon, 17 Jul 2000, Shane Hathaway wrote:
>
> > "Jeff K. Hoffman" wrote:
> >
> > > Do I need to commit or abort even if I don't make changes to the
> > > application object? The only thing I need it for is to get to the
> > > Control_Panel; I am instantiating ZClass instances in the
> constructor of a
> > > Python class, i.e.:
> > >
> > > class MyClass:
> > >
> > > def __init__(self, id, title=''):
> > > import Zope
> > > app = Zope.app()
> > >
> > > ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> > > ob.id = 'newId'
> > >
> > > self._setObject('newId', ob)
> > >
> > > # Do I need a get_transaction().abort() here? Will
> that not abort
> > > # the wrong transaction?
> > >
> > > app._p_jar.close()
> > >
> >
> > Hmm... you're creating an object in a separate connection
> (I would call
> > get_transaction().abort() just to be on the safe side...)
> then copying
> > that object over to the existing connection. This will
> probably work,
> > but I wouldn't be surprised to see thorny bugs appear.
>
> I have just hit one such thorny bug. Oh well. :-)
>
> > If you could instead get a handle to the existing
> connection, you'd be
> > following standard practice. You probably have a
> manage_addMyClass()
> > method, don't you? The "self" argument provided to that method is
> > already connected to the database. self.getPhysicalRoot() will give
> > you the equivalent of the app object. Then just change your
> > constructor this way:
> >
> > > def __init__(self, app, id, title=''):
> > > ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> > > ob.id = 'newId'
> > >
> > > self._setObject('newId', ob)
>
> Yeah, I was there, and that worked great. Then, I started
> implementing my
> __setstate__ method to "upgrade" old instances of my python
> class. I need
> to access the connection from here, too, and this is where the trouble
> begins.
>
> AFAICT, I cannot call self.getPhysicalRoot() from
> __setstate__, for the
> same reason I can't call it from __init__. I can get by the __init__
> problem by passing app in as an argument from
> manage_addMyProduct(). I can
> find no such solution for __setstate__.
>
> > Best of luck!
> >
> > Shane
>
> All of my efforts are progressing towards one goal: How do I upgrade
> existing instances of a ZClass? Since I could find no
> __setstate__ method
> for ZClasses, I re-wrote the containing class as a Python class and
> figured I could leverage __setstate__ there, instantiating
> the subordinate
> ZClasses when required.
>
> No such luck.
>
> I am going to spend a little more time working on this. If I
> can't find a
> solution, I may drop ZClasses altogether and move all my code
> to Python. I
> had hoped not to do this, because my web guys can work with
> ZClasses but
> have no clue where to begin with a Python Product.
>
> I may just have to take total ownership of the code, as much
> as I dislike
> the idea, if I can find no other solution.
>
> --Jeff
>
> ---
> Jeff K. Hoffman 704.849.0731 x108
> Chief Technology Officer
mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
On Mon, 17 Jul 2000, Shane Hathaway wrote:
> "Jeff K. Hoffman" wrote:
>
> > Do I need to commit or abort even if I don't make changes to the
> > application object? The only thing I need it for is to get to the
> > Control_Panel; I am instantiating ZClass instances in the constructor of a
> > Python class, i.e.:
> >
> > class MyClass:
> >
> > def __init__(self, id, title=''):
> > import Zope
> > app = Zope.app()
> >
> > ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> > ob.id = 'newId'
> >
> > self._setObject('newId', ob)
> >
> > # Do I need a get_transaction().abort() here? Will that not abort
> > # the wrong transaction?
> >
> > app._p_jar.close()
> >
>
> Hmm... you're creating an object in a separate connection (I would call
> get_transaction().abort() just to be on the safe side...) then copying
> that object over to the existing connection. This will probably work,
> but I wouldn't be surprised to see thorny bugs appear.
I have just hit one such thorny bug. Oh well. :-)
> If you could instead get a handle to the existing connection, you'd be
> following standard practice. You probably have a manage_addMyClass()
> method, don't you? The "self" argument provided to that method is
> already connected to the database. self.getPhysicalRoot() will give
> you the equivalent of the app object. Then just change your
> constructor this way:
>
> > def __init__(self, app, id, title=''):
> > ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> > ob.id = 'newId'
> >
> > self._setObject('newId', ob)
Yeah, I was there, and that worked great. Then, I started implementing my
__setstate__ method to "upgrade" old instances of my python class. I need
to access the connection from here, too, and this is where the trouble
begins.
AFAICT, I cannot call self.getPhysicalRoot() from __setstate__, for the
same reason I can't call it from __init__. I can get by the __init__
problem by passing app in as an argument from manage_addMyProduct(). I can
find no such solution for __setstate__.
> Best of luck!
>
> Shane
All of my efforts are progressing towards one goal: How do I upgrade
existing instances of a ZClass? Since I could find no __setstate__ method
for ZClasses, I re-wrote the containing class as a Python class and
figured I could leverage __setstate__ there, instantiating the subordinate
ZClasses when required.
No such luck.
I am going to spend a little more time working on this. If I can't find a
solution, I may drop ZClasses altogether and move all my code to Python. I
had hoped not to do this, because my web guys can work with ZClasses but
have no clue where to begin with a Python Product.
I may just have to take total ownership of the code, as much as I dislike
the idea, if I can find no other solution.
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
Chris McDonough wrote: > > So it's kosher then to reimport the Zope module and use app() in a > constructor method, Shane? I was always afraid it would do something > horrible. Now that I've read this again I realize what you're saying. You're right, what happens is you get two connections associated with one thread. The behavior of get_transaction() might not be what's expected. Someone tried something like this before in a product months ago. A bug was discovered and fixed, but the product author eventually found a better way anyway. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
"Jeff K. Hoffman" wrote:
> Do I need to commit or abort even if I don't make changes to the
> application object? The only thing I need it for is to get to the
> Control_Panel; I am instantiating ZClass instances in the constructor of a
> Python class, i.e.:
>
> class MyClass:
>
> def __init__(self, id, title=''):
> import Zope
> app = Zope.app()
>
> ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> ob.id = 'newId'
>
> self._setObject('newId', ob)
>
> # Do I need a get_transaction().abort() here? Will that not abort
> # the wrong transaction?
>
> app._p_jar.close()
>
Hmm... you're creating an object in a separate connection (I would call
get_transaction().abort() just to be on the safe side...) then copying
that object over to the existing connection. This will probably work,
but I wouldn't be surprised to see thorny bugs appear.
If you could instead get a handle to the existing connection, you'd be
following standard practice. You probably have a manage_addMyClass()
method, don't you? The "self" argument provided to that method is
already connected to the database. self.getPhysicalRoot() will give
you the equivalent of the app object. Then just change your
constructor this way:
> def __init__(self, app, id, title=''):
> ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> ob.id = 'newId'
>
> self._setObject('newId', ob)
Best of luck!
Shane
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
Chris McDonough wrote: > > So it's kosher then to reimport the Zope module and use app() in a > constructor method, Shane? I was always afraid it would do something > horrible. You certainly should not call reload(Zope), but the semantics of import are smart enough to only execute the module the first time it's imported. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
So it's kosher then to reimport the Zope module and use app() in a
constructor method, Shane? I was always afraid it would do something
horrible.
> -Original Message-
> From: Jeff K. Hoffman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 17, 2000 1:11 PM
> To: Shane Hathaway
> Cc: Chris McDonough; 'Jeff K. Hoffman'; [EMAIL PROTECTED]
> Subject: Re: [Zope-dev] The Application object
>
>
> On Mon, 17 Jul 2000, Shane Hathaway wrote:
>
> > The way to get the root application object is to open a
> connection to
> > the ZODB and get the 'Application' object from the list of root
> > objects. There is an easy shortcut:
> >
> > import Zope
> > app = Zope.app()
> >
> > app now refers to a *copy* of the root Application object.
>
> Yeehaw, that worked! I was so close. :-)
>
> > When you're done modifying it and its descendants you have
> to commit or
> > abort the transaction.
>
> [snip]
>
> Do I need to commit or abort even if I don't make changes to the
> application object? The only thing I need it for is to get to the
> Control_Panel; I am instantiating ZClass instances in the
> constructor of a
> Python class, i.e.:
>
> class MyClass:
>
> def __init__(self, id, title=''):
> import Zope
> app = Zope.app()
>
> ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
> ob.id = 'newId'
>
> self._setObject('newId', ob)
>
> # Do I need a get_transaction().abort() here? Will that
> not abort
> # the wrong transaction?
>
> app._p_jar.close()
>
> ...
>
> > This gives you all kinds of benefits like undo and elimination of
> > threading conflicts.
>
> [snip]
>
> Good stuff. Thanks, Shane.
>
> > Shane
>
> --Jeff
>
> ---
> Jeff K. Hoffman 704.849.0731 x108
> Chief Technology Officer
mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
On Mon, 17 Jul 2000, Shane Hathaway wrote:
> The way to get the root application object is to open a connection to
> the ZODB and get the 'Application' object from the list of root
> objects. There is an easy shortcut:
>
> import Zope
> app = Zope.app()
>
> app now refers to a *copy* of the root Application object.
Yeehaw, that worked! I was so close. :-)
> When you're done modifying it and its descendants you have to commit or
> abort the transaction.
[snip]
Do I need to commit or abort even if I don't make changes to the
application object? The only thing I need it for is to get to the
Control_Panel; I am instantiating ZClass instances in the constructor of a
Python class, i.e.:
class MyClass:
def __init__(self, id, title=''):
import Zope
app = Zope.app()
ob = app.Control_Panel.Products.MyProduct.MyZClass('newId')
ob.id = 'newId'
self._setObject('newId', ob)
# Do I need a get_transaction().abort() here? Will that not abort
# the wrong transaction?
app._p_jar.close()
...
> This gives you all kinds of benefits like undo and elimination of
> threading conflicts.
[snip]
Good stuff. Thanks, Shane.
> Shane
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The Application object
Chris McDonough wrote:
>
> > Sorry I wasn't clear enough. The Singleton is a design
> > pattern from the
> > Gang of Four book that fits this situation well. It is a
> > class that is
> > meant to control access to the one and only instance of a global
> > variable. I was just using that as a frame of reference,
> > though; Zope has
> > no such class for the Application object, or I wouldn't be
> > writing this
> > message.
>
> Oh, ok, sorry, hard to tell intent from actual code. :-)
>
> >
> > I just need some way of getting at the one and only
> > Application object at
> > run-time. Something like:
> >
> > from Globals import app
> > myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
> > ...
> >
> > Given a reference to an object in the ZODB, I can do this via:
> >
> > app = self.getPhysicalRoot()
> > myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
> >
> > But, this does not work from methods like __init__, or
> > __setstate__, where
> > we do not have a physical location in the ZODB, yet.
>
> Ah, I see the problem.
>
> I'm afraid I don't know the answer.
>
> I generally use the manage_afterAdd and manage_beforeDelete methods to
> do things like this.
>
> I suppose you could pass the root object into the constructor.
> __setstate__... well. Err...
>
> Anybody else?
The way to get the root application object is to open a connection to
the ZODB and get the 'Application' object from the list of root
objects. There is an easy shortcut:
import Zope
app = Zope.app()
app now refers to a *copy* of the root Application object. When you're
done modifying it and its descendants you have to commit or abort the
transaction.
get_transaction().commit() (or abort())
This gives you all kinds of benefits like undo and elimination of
threading conflicts. You *must* remember to close the connection:
app._p_jar.close()
Shane
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
> Sorry I wasn't clear enough. The Singleton is a design
> pattern from the
> Gang of Four book that fits this situation well. It is a
> class that is
> meant to control access to the one and only instance of a global
> variable. I was just using that as a frame of reference,
> though; Zope has
> no such class for the Application object, or I wouldn't be
> writing this
> message.
Oh, ok, sorry, hard to tell intent from actual code. :-)
>
> I just need some way of getting at the one and only
> Application object at
> run-time. Something like:
>
> from Globals import app
> myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
> ...
>
> Given a reference to an object in the ZODB, I can do this via:
>
> app = self.getPhysicalRoot()
> myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
>
> But, this does not work from methods like __init__, or
> __setstate__, where
> we do not have a physical location in the ZODB, yet.
Ah, I see the problem.
I'm afraid I don't know the answer.
I generally use the manage_afterAdd and manage_beforeDelete methods to
do things like this.
I suppose you could pass the root object into the constructor.
__setstate__... well. Err...
Anybody else?
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
On Mon, 17 Jul 2000, Chris McDonough wrote:
> I'm not sure I understand. What is AppSingleton? What does the
> Instance() method do?
Sorry I wasn't clear enough. The Singleton is a design pattern from the
Gang of Four book that fits this situation well. It is a class that is
meant to control access to the one and only instance of a global
variable. I was just using that as a frame of reference, though; Zope has
no such class for the Application object, or I wouldn't be writing this
message.
I just need some way of getting at the one and only Application object at
run-time. Something like:
from Globals import app
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
...
Given a reference to an object in the ZODB, I can do this via:
app = self.getPhysicalRoot()
myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo')
But, this does not work from methods like __init__, or __setstate__, where
we do not have a physical location in the ZODB, yet.
I just need a reference to the app object. I know the answer has to be
simple, but I can't find it.
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] The Application object
I'm not sure I understand. What is AppSingleton? What does the Instance() method do? > -Original Message- > From: Jeff K. Hoffman [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 17, 2000 11:54 AM > To: [EMAIL PROTECTED] > Subject: [Zope-dev] The Application object > > > Hello, > > What is the easiest way for me to get ahold of the > Application object at > run-time? > > I am writing a Product that needs to access some things in the > Control_Panel, and need the app object to get there. > > I know how to do it given a reference to an object in the ZODB > (getPhysicalRoot(), etc.), but need a way to do it given no > references. I > need something like: > > import AppSingleton > > app = AppSingleton.Instance() > app.Control_Panel.blah > > --Jeff > > --- > Jeff K. Hoffman 704.849.0731 x108 > Chief Technology Officer > mailto:[EMAIL PROTECTED] > Going Virtual, L.L.C. http://www.goingv.com/ > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
