Alexander Staubo wrote:
To answer your first question, let your "parent" ZClass be a
descendant
of Object Manager; then define your "child" ZClass _within_ the parent ZClass definition; that is, add the child ZClass as a subobject of the parent.
I assume that you mean that I should create the 'child' ZClass within the 'Methods' tab of the parent?
Yes, that's how it's supposed to work, odd as it may seem. Never tried this myself, though.
Your second question is trickier, because Zope does not, afaik, support properties that are objects. It's possible, but I believe you can't edit these properties through the standard management interfaces. Instead, you must built your own, and you might have to use Python to store these properties.
Hmm, seems a pretty important feature, does anyone know if this sort of functionality is on the drawing board for the Zope interface?
Post it to the Collector (http://www.zope.org/Collector) if you think it's important. I agree; but this prompt the question: "Yes, but how?" Should you be able to define properties that can accept only one type of object? Several types? Any type of object? Another aspect is interdependencies -- you might want to introduce deletion constraint on which objects may be deleted if they're referenced, and so on.
The alternative, of course, is to use a string property and refer to the object's ID. Acquisition will permit you to access any object in the hierarchy above the object in question.
Do you have an example of a simple working application that uses this technique?
Nope, but assuming that document Foo has a string property OtherObject, you can do this(untested):: Other object's id is: <!--#var "_[OtherObject].id()"--> Title of that object is: <!--#var "_[OtherObject].title_or_id()"--><br> Result of osme method call: <!--#var "_[OtherObject].GetSomething(this())"--><br>
And what happens when the pointed-to object is deleted or modified?
Nothing, so you should do something like this in the documents that use the contents of the property:: <!--#if "not HasAttr(PARENTS[0], OtherObject)"--> <!--#call "manage_changeProperties({'OtherObject': ''})"--> <!--#/if--> or something like that, assuming HasAttr() is an External Method that tests for the existence of a property (I have not found this functionality in Zope's built-in DTML API: The closest I you get is getattr, which raises an error if it fails). I implement this function like so:: def HasAttr(o, attr): return hasattr(o, attr) -- Alexander Staubo http://www.mop.no/~alex/ "What the hell, he thought, you're only young once, and threw himself out of the window. That would at least keep the element of surprise on his side." --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
Alexander Staubo wrote:
Hmm, seems a pretty important feature, does anyone know if this sort of functionality is on the drawing board for the Zope interface?
Post it to the Collector (http://www.zope.org/Collector) if you think it's important. I agree; but this prompt the question: "Yes, but how?" Should you be able to define properties that can accept only one type of object? Several types? Any type of object? Another aspect is interdependencies -- you might want to introduce deletion constraint on which objects may be deleted if they're referenced, and so on.
As far as object constraints are concerned, I was actually thinking of a constraint by metatype, so that if you have several types of objects you want to reference from a single attribute pointer, they should probably inherit from a common base class. Interdependencies -- well, frankly I hadn't given that much thought. you would probably have to deal with it on a case by case basis. I think it may be too application dependent, although a deletion mechanism that replaces references to a deleted object with references to another object of the same type might be handy. Example: someone in the sales dept. is fired, so he is deleted from the system. when being deleted, the system could ask which other instance of 'salesman' should replace the references to the deleted instance. This is of course, not a very good example, as this would not only assign the fired salesman's customers to someone, but in all likelihood also add all of the deleted salesman's prior sales towards the second guys quotas. So there may be no way around custom deletion methods in complex applications. If anyone else agrees with Alexander and myself that being able to assign 'pointers to objects' as attributes ( as opposed to actually instantiating an object as an attribute) would be a good addition to the Zope interface, let me know, and I'll incorporate your suggestions before I post this to the Collector. OTOH, if you disagree, and don't want this cluttering up the Collector, let me know that too. Michael Bernstein.
participants (2)
-
Alexander Staubo -
Michael Bernstein