Hi Rik. 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...
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 ;-(
That is ok. Knowing that an object is 'Folderish' would be enough of a clue for example to provide a standarised image 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.
That is of course right. But let me point out a little example I have in mind: Right now I am constructing a container object to which arbitrary files can be uploaded and it is then dislplayed within a table. For that purpose I created a container object which can contain very general "document objects". To those I provided some basic information which must be included into every upload (description, timestamp and who-did-the-upload stuff). I thought it would be nice to derive some objects from this baseclass (dokument) which can have more properties (keywords, references etc.). On an abstract level I basically want to do the same with these objects: display them (plus properties) in a table. This could generally be done by method overloading. Ok so far. Since it could be possible to mix several dokument-sub classes in one container it would be very nice NOT to name the items to be enumerated explicitly (like providing more arguments to the objectValues method). Right now I could use the "feature" of polymorphism very much. That was what raised my question. If there is no such thing a polymorphism... well I can live with that and do some workarounds. After all it would "only" be very comfortable to simply do method overloading and let Zope call the right method. This would enable a single declaration of <dtml-in "objectValues(['Dokument'])"> [display data here, even from derived objects] </dtml-in> instead of adjusting the parameter with every new sub-class of Dokument. Regards, Ingo ------------------------------------------