Hi about something like this (External method): # # # Check a classes base types for a certain meta_type... # # def checkClassMetaType(theClass, meta_type): """ check a class... and all super classess for meta_type....""" result = 0 if theClass.meta_type == meta_type: result = 1 else: for subClass in theClass.__bases__: result = checkClassMetaType( subClass, meta_type) if result: break return result def checkObjectMetaType(self, object, meta_type): """ check and object for an ancestral meta_type...""" if object.meta_type == meta_type: return 1 else: return checkClassMetaType(object.__class__, meta_type) ----------------------------------------------------------------------
"Ingo" == Ingo Assenmacher <ingo.assenmacher@post.rwth-aachen.de> writes:
Ingo> Hi Rik. Ingo> Am 09-Feb-00 schrieb Rik Hoekstra: >>> Thats really ugly having to know the distingishing method >>> names. Isn't there some method like >>> _.inheritsfrom(_['sequence-item'],'Folder') >>> >> This doesn't look very nice to me... Ingo> No, it does not... but it would come in handy... :) >> You could test whether an object was 'Folderish', but at the >> moment I have neither a clue how to do it ;-\ nor the time to >> sort it out ;-( >> Ingo> That is ok. Knowing that an object is 'Folderish' would be Ingo> enough of a clue for example to provide a standarised image Ingo> for a folder object within a tree. >> but you can give objectValues more arguments (the argument _is_ >> a list). So that would mean in this case >> >> <dtml-in "objectValues(['Folder', >> 'UploadFolder',AnyOtherMetatypeYouCanThinkOf, ...])"> [bla] >> </dtml-in> >> >> Note that this can include any metatype you want, not just >> folders or 'folderish' objects. If you want you can filter them >> further using their attributes, properties or whatever. Ingo> That is of course right. But let me point out a little Ingo> example I have in mind: Ingo> Right now I am constructing a container object to which Ingo> arbitrary files can be uploaded and it is then dislplayed Ingo> within a table. For that purpose I created a container Ingo> object which can contain very general "document objects". To Ingo> those I provided some basic information which must be Ingo> included into every upload (description, timestamp and Ingo> who-did-the-upload stuff). I thought it would be nice to Ingo> derive some objects from this baseclass (dokument) which can Ingo> have more properties (keywords, references etc.). On an Ingo> abstract level I basically want to do the same with these Ingo> objects: display them (plus properties) in a table. This Ingo> could generally be done by method overloading. Ok so Ingo> far. Since it could be possible to mix several dokument-sub Ingo> classes in one container it would be very nice NOT to name Ingo> the items to be enumerated explicitly (like providing more Ingo> arguments to the objectValues method). Right now I could use Ingo> the "feature" of polymorphism very much. That was what Ingo> raised my question. If there is no such thing a Ingo> polymorphism... well I can live with that and do some Ingo> workarounds. After all it would "only" be very comfortable Ingo> to simply do method overloading and let Zope call the right Ingo> method. This would enable a single declaration of Ingo> <dtml-in "objectValues(['Dokument'])"> [display data here, Ingo> even from derived objects] </dtml-in> Ingo> instead of adjusting the parameter with every new sub-class Ingo> of Dokument. Ingo> Regards, Ingo Ingo> ------------------------------------------ Ingo> _______________________________________________ Zope Ingo> maillist - Zope@zope.org Ingo> http://lists.zope.org/mailman/listinfo/zope ** No cross Ingo> posts or HTML encoding! ** (Related lists - Ingo> http://lists.zope.org/mailman/listinfo/zope-announce Ingo> http://lists.zope.org/mailman/listinfo/zope-dev )