Re: RE: [Zope] Another import doesn't find the module
Tom's solution has not worked. But he has offered me more help tomorrow to find a solution.
Why not create a single product that can instantiate itself (or subobjects) more than one way?
The product I am creating is more like an application. It has container objects at the top, and several subfolders that contain hundreds of objects that make up a 'record'. I guess you can say I have tons of data models to go in this application. My whole problem is trying to get things to instantiate more than one way. Once a user has created a record of type #1, he must have the ability to go back and add an extension of type A. In doing this, It alters the way type #1 initially existed. I can't force the user to create a record of tye #1 with the type A extension up front. If only it were that easy, I wouldn't be having such a pain. ----- Original Message ----- From: Dylan Reinhardt <zope@dylanreinhardt.com> Date: Wednesday, May 28, 2003 3:43 pm Subject: Re: RE: [Zope] Another import doesn't find the module
On Wed, 2003-05-28 at 12:33, Stacy Roberts Ladnier wrote:
The line I had that read from Products.Resources.FGDC import profile failed.
Before class1 of DISTINFO.py, I tried the above statement and recieve a 'can't import name profile'.
However, this line works like a charm: from Products.Resources.FGDC import DISTRIB
and is located directly under the above line. Totally baffling me.
Is the solution Tom gave you not working?
Distinfo #1 is in the FGDC directory. Distinfo #2 will
live in
the extensions directory. I want to set of a script in the scripts directory that will cause the #2 to be added. By the way, both of these objects(#1 and #2) should have the same metatype.
This sounds like a pretty brittle system. Why not create a single product that can instantiate itself (or subobjects) more than one way?
Dylan
On Wed, 2003-05-28 at 18:13, Stacy Roberts Ladnier wrote:
Why not create a single product that can instantiate itself (or subobjects) more than one way?
The product I am creating is more like an application.
Excellent.
It has container objects at the top,
Cool.
and several subfolders
OK.
that contain hundreds of objects
Yeah.
that make up a 'record'.
Hundreds of objects == one "record"? Hmmm...
I guess you can say I have tons of data models to go in this application.
That's not typically a hallmark of good design or an easily-supported system, but I'm not the one with the requirements in front of me.
My whole problem is trying to get things to instantiate more than one way.
Ah... well, in that case I have a couple cool tricks to share.
Once a user has created a record of type #1, he must have the ability to go back and add an extension of type A.
So... this is a "record" in the same sense as above where a record is defined by hundreds of ZMI objects? Does the "extension" consist of an additional object added through the ZMI? Or do you just want your type #1 object to have a new interface?
I can't force the user to create a record of tye #1 with the type A extension up front.
Why not? Anything a user can do, Zope can do for them.
If only it were that easy, I wouldn't be having such a pain.
Often when things are difficult in Zope (and open source in general), it is because one is unaware that someone else already solved the problem. Leaving that aside, there's a couple different ways you could attack the problem of returning different types of instances If you want the decision made at instantiation time, you can do that in your constructor method: -------- manage_addMyThing(self, id, REQUEST=None): if some_test: self._setObject(id, Class1(id)) else: self._setObject(id, Class2(id)) class Class1: def __init__(self, id): self.id = id meta_type = 'MyThing' class Class2: def __init__(self, id): self.id = id meta_type = 'MyThing' -------- You'll want to ensure that both classes either have the same interface (recommended) or at least have an intelligent way of failing when a given interface isn't found. Having them both inherit from a base class is an approach well worth considering. If you want to be able to change classes on the fly, that's a bit trickier, but not by much. ------ class One: def __init__(self, name): self.name = name def whoami(self): return self.name class Two: def __init__(self, name): self.name = name def whoami(self): return "I am %s, a class Two object." % self.name def SwitchClass(object, target_class): if target_class == 'One': new_obj = One(object.name) if target_class == 'Two': new_obj = Two(object.name) new_obj.__dict__ = object.__dict__ return new_obj ------- If you entered these classes into an interactive prompt, you can then see how easily you can change back and forth:
a = One('my thing') a.foo = 'this is the foo attribute' a.whoami() 'my thing' a = SwitchClass(a, 'Two') a.whoami() 'I am my thing, a class Two object.' a.foo 'this is the foo attribute'
The execution in a Python product may be a bit more sophisticated, but the general idea is the same. Python makes it pretty easy to change stuff on the fly and makes it easy to use objects polymorphically so that what type your object is often doesn't matter very much. Hope that helps and if you want to hash out some possible alternatives to your data model, let us know. Dylan
Dylan Reinhardt wrote:
Hundreds of objects == one "record"? Hmmm...
What I call a record is a container object that holds hundreds of objects that make up the data elements of that record.
Ah... well, in that case I have a couple cool tricks to share.
Any tips woulds be appreciated. I am still a zope newbie believe it or not.
So... this is a "record" in the same sense as above where a record is defined by hundreds of ZMI objects? Does the "extension" consist of an additional object added through the ZMI? Or do you just want your type #1 object to have a new interface?
yes it is the same "record". The extension is an additional object.
I guess you can say I have tons of data models to go in this application.
That's not typically a hallmark of good design or an easily-supported system, but I'm not the one with the requirements in front of me
My requirements are extremely complicated and I have no choice but to have several different data models in the same application. I am trying to make the best design possible.
.
I can't force the user to create a record of tye #1 with the type A extension up front.
This is a requirement. And since yesterday, of course, the requirements have changed. So, now I don't have to solve this problem just yet.
The information you provided me about switching classes after instantiation was excellent. I was unaware of the ability to do this. I might say I am new to Python (a few months young) and have my background in Java, which should explain such stupidity on my part. I am not use to having such flexibility. You have helped me greatly and I appreciate it to the fullest. Stacy
On Thu, May 29, 2003 at 08:25:19AM -0500, Stacy Roberts Ladnier wrote:
So... this is a "record" in the same sense as above where a record is defined by hundreds of ZMI objects? Does the "extension" consist of an additional object added through the ZMI? Or do you just want your type #1 object to have a new interface?
yes it is the same "record". The extension is an additional object.
Does the container / record need to have different or new behavior when this extension object is added to it? Or is the difference encapsulated in the extension object? If the latter, I don't see why you need to muck about with changing the class of the container at all. I must be missing something... Even in the former case, you could handle the variance by checking whether the record contains any of these extension objects, assuming they're easily identifiable (either by id or by isinstance(foo, klass)). Of course that might not be cleaner if the difference in behavior is extensive. Sorry if I'm stating the obvious, or missing the point entirely... -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's SLIM CACTUS BLAZER! (random hero from isometric.spaceninja.com)
On Thu, 2003-05-29 at 06:25, Stacy Roberts Ladnier wrote:
My requirements are extremely complicated and I have no choice but to have several different data models in the same application. I am trying to make the best design possible.
Fair enough.
I might say I am new to Python (a few months young) and have my background in Java, which should explain such stupidity on my part. I am not use to having such flexibility.
Yeah, Python is pretty cool language... one well worth spending some time with. You may find these links helpful and/or interesting as you progress further with Python: http://diveintopython.org/toc.html http://aspn.activestate.com/ASPN/Python/Cookbook/ Dylan
participants (3)
-
Dylan Reinhardt -
Paul Winkler -
Stacy Roberts Ladnier