Ingo Assenmacher <ingo.assenmacher@post.rwth-aachen.de> wrote:
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
Or, as an alternative, we could extend the <dtml-in> tag to pass in a filter expression as an additional argument:: <dtml-in name=objectValues filter="self.hasMetaType( 'Document' )"> The implementation would likely need to construct a Python code object by synthesizing a function around the expression (or else we could expose lambda to DTML :). Tres. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
Hi Tres! Am 10-Feb-00 schrieb Tres Seaver:
Or, as an alternative, we could extend the <dtml-in> tag to pass in a filter expression as an additional argument::
<dtml-in name=objectValues filter="self.hasMetaType( 'Document' )">
The implementation would likely need to construct a Python code object by synthesizing a function around the expression
That would be absolutely ok of course. Can I be of any help? Regards, Ingo ------------------------------------------
Ingo Assenmacher wrote:
Hi Tres!
Am 10-Feb-00 schrieb Tres Seaver:
Or, as an alternative, we could extend the <dtml-in> tag to pass in a filter expression as an additional argument::
<dtml-in name=objectValues filter="self.hasMetaType( 'Document' )">
The implementation would likely need to construct a Python code object by synthesizing a function around the expression
That would be absolutely ok of course. Can I be of any help?
On further thought, this is better solved by repeating <dtml-forever> <dtml-mantra> Separate content from presentation! </dtml-mantra> </dtml-forever> More seriously, PythonMethods are the Right Thing (TM) here. For example:: PM ID: folderishOnly Parameters: self Body: ------------------------------ result = [] for obj in self.objectValues(): if obj.isPrincipiaFolderish: result.append( obj ) return result ------------------------------ Then I write in DTML: <dtml-in folderishOnly> </dtml-in> This is better, by almost any criteria, than mangling the filter expression into the <dtml-in> tag. P.S.: This would be even cooler, except PythonMethods don't have map/filter available: return _.filter( isPrincipiaFolderish, self.objectValues() ) Actually, given _.filter, one could do this in DTML: <dtml-in expr="_.filter( isPrincipiaFolderish, self.objectValues() )"> -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
----- Original Message ----- From: Tres Seaver <tseaver@palladion.com>
Or, as an alternative, we could extend the <dtml-in> tag to pass in a filter expression as an additional argument::
<dtml-in name=objectValues filter="self.hasMetaType( 'Document' )">
On further thought, this is better solved by repeating
<dtml-forever> <dtml-mantra> Separate content from presentation! </dtml-mantra> </dtml-forever>
More seriously, PythonMethods are the Right Thing (TM) here.
I disagree ;-) Not that PMs aren't good for this; they are, of course. But I'd hate to have to write one for something this piddling when the extension really wouldn't be that bad: <dtml-in objectValues filter="meta_type == 'DTML Document'"> If the condition was more complex, then I would lean towards encapsulating it in a PM, and writing: <dtml-in objectValues filter=LeftHandedWuzzleWidgets> This allows you some orthogonality between your condition and the sequence you're applying it to.
P.S.: This would be even cooler, except PythonMethods don't have map/filter available:
I'm still not sure why DTML leaves out filter and reduce. 'map' I can sort of understand, but not the other two. Put them in DTML, and PMs get them automatically. Cheers, Evan @ digicool
Evan Simpson wrote:
----- Original Message ----- From: Tres Seaver <tseaver@palladion.com>
Or, as an alternative, we could extend the <dtml-in> tag to pass in a filter expression as an additional argument::
<dtml-in name=objectValues filter="self.hasMetaType( 'Document' )">
On further thought, this is better solved by repeating
<dtml-forever> <dtml-mantra> Separate content from presentation! </dtml-mantra> </dtml-forever>
More seriously, PythonMethods are the Right Thing (TM) here.
I disagree ;-) Not that PMs aren't good for this; they are, of course. But I'd hate to have to write one for something this piddling when the extension really wouldn't be that bad:
<dtml-in objectValues filter="meta_type == 'DTML Document'">
Ah, I was not advocating removing the argument from object values -- I was backtracking on the idea of adding a "filter=" attribute to the <dtml-in> tag. I changed my ground because, for anything more complicated than the simple meta_type check, the design "smells better" if I factor the filtering out to a PythonMethod (it gets much easier to reuse or parameterize the logic, for instance).
If the condition was more complex, then I would lean towards encapsulating it in a PM, and writing:
<dtml-in objectValues filter=LeftHandedWuzzleWidgets>
Or just:: <dtml-in LeftHandedWuzzleWidgets>
This allows you some orthogonality between your condition and the sequence you're applying it to.
P.S.: This would be even cooler, except PythonMethods don't have map/filter available:
I'm still not sure why DTML leaves out filter and reduce. 'map' I can sort of understand, but not the other two. Put them in DTML, and PMs get them automatically.
Blocking the "simple" uses of map (apply a function to each item in a list) makes no sense: that is logically no different than removing <dtml-in>! Funkier uses, like splicing parallel lists into lists of tuples, maybe. I agree that adding filter and reduce would be dead easy; I don't use reduce much myself, but filter would be really nice to have. Adding a filter= keyword to the <dtml-in> tag doesn't quite do it -- applying an arbitrary filter expression to the objects one normally iterates over seems non-trivial, at least without munging in lambda, too (I can hear the screams already!). I guess one could require that the filter attribute name a callable (as in your example above). Best, Tres. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
participants (3)
-
Evan Simpson -
Ingo Assenmacher -
Tres Seaver