Thanks so much for the response... It turns out, I tried the Python Method and it had the same basic problem as the DTML Method... however I've now moved on, using deletageRetrieve to a new thorny issue. ;-) When I get an object from of another specialist it appears that it doies not inherit from my specialist, but from *its* specialist. (e.g., my framework specialist has methods that I want the dataskins to acquire). I've currently got it wrapped like so: def retrieveItem(self, key): """ get an item....""" return self.delegateRetrieve(self, None, key=key).__of__(self) I've tried several different combinations of __of__ etc, but none of them seems to allow the dataskin to acquire, for example, standard_html_header from my specialist. Is there any way to enforce acquisition at this level? thanks! -steve
"pje" == Phillip J Eby <pje@telecommunity.com> writes:
pje> At 08:00 AM 9/25/00 -0500, Steve Spicklemire wrote: >> So my retrieve item gets called..... *unfortunately* it gets >> called without any namespace parameter... so my retrieveItem >> DTML method has no way to acquire a namespace so that it can >> delagate to something else! >> >> So... here is what I did... I defined a method in my Python >> subclass of Specialist.. >> >> class MarketItemManager(ZPatterns.Specialists.Specialist): """A >> Market Item Manager""" >> >> # Specify a name for the item type: >> meta_type='MarketItemManager' >> >> def retrieveItem(self, key): """ get an item....""" return >> self.__of__(self).delegateRetrieve(self, None, key=key) >> >> Then I made a DTML method called 'delegateRetrieve' like so: >> >> <dtml-return "myGreatSite.ThingManager.getItem(key)"> >> >> this way, my integrator can edit 'delegateRetrieve' to point to >> whatever Specialist he wants to... and I have a Python >> implementation of retrieveItem. >> >> Does this sound OK? Am I working way too hard here? (I feel >> like I am! ;-> ) >> pje> Remember in the code where I have "# XXX DTML check?" That's pje> because I was anticipating your problem, but since I didn't pje> personally need to do what you're doing yet, I didn't pje> implement it. For one thing, I was waiting to see if Zope pje> core method binding would get fixed. Unfortunately, I'm not pje> sure that Zope method binding is going to be available for pje> anything but PythonMethods in 2.3. As of right now, however, pje> you should be able to use a PythonMethod for retrieveItem, pje> rather than a DTML Method, and it should work. pje> In short, even now, delegateRetrieve should not be necessary. pje> You should be able to implement retrieveItem using a pje> PythonMethod or a DTML Document rather than a DTML Method. pje> (I say *should* because I have not tried it personally.)