Re: [Zope-dev] Functional programming
Lalo Martins <lalo@hackandroll.org> asks:
To: zope-dev@zope.org Subject:
I know it probably is on the archives, but I didn't find it.
Is there a good reason why I can't use map, filter and lambda in DTML code? (They're not in the namespace.)
Duncan Booth <duncan@rcp.co.uk> replies:
lambda is available, but you have to specify an extra default argument _vars=_vars
Is there a good reason why I can't use map, filter and lambda in DTML code? (They're not in the namespace.)
Even without map and filter this can be useful on occasion if you find yourself otherwise repeating an expression a lot of times. On the other hand it isn't very pleasant to look at.
I think the answer is probably that if you find you need to use map and filter then you should consider using Python instead. Besides you can get the effect of both of these with dtml-in.
Lalo volleys:
I think the answer is probably that if you find you need to use map and filter then you should consider using Python instead.
Not really. Practical example:
<dtml-in "map (Catalog.get_object, Catalog(...))"> perform some operation, like listing the objects, without need to bload the Catalog with all properties in the objects </dtml-in>
The downside here is that you activate every object found, which can be deadly for a really large result set. The rationale for using meta_data is to allow presentation of a limited view of the catalogued objects without pulling them into memory from the ZODB.
And even if I _should_ use Python, then it should at least be supported in PythonMethods.
PythonMethods have no more access than DTML Methods/Documents (by design).
Besides you can get the effect of both of these with dtml-in.
But the code you need for that looks mightly ugly, with temporary variables, lots of REQUEST.set... let's not go there :-)
Agreed. filter() is particularly nice, as it eliminates the nesting of the <dtml-if> inside the <dtml-in>. For instance, to grab all contained objects which have a "browseable" property, set to true: <dtml-in "_.filter( lambda x: x.hasattr( 'browseable' ) and x.browseabe, objectValues() )"> ... </dtml-in> I will admit that I can't think of a particular use for map() offhand (but then, I'm not a lambda-head, either). -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
On Thu, Feb 24, 2000 at 11:04:19AM -0600, Tres Seaver wrote:
Lalo volleys:
Not really. Practical example:
<dtml-in "map (Catalog.get_object, Catalog(...))"> perform some operation, like listing the objects, without need to bload the Catalog with all properties in the objects </dtml-in>
The downside here is that you activate every object found, which can be deadly for a really large result set. The rationale for using meta_data is to allow presentation of a limited view of the catalogued objects without pulling them into memory from the ZODB.
I realize that, but it's pretty useful when I'm sure the set will be small (by constraining the Catalog call, for example). Come think of it, sometimes I don't _want_ a "limited" view, and the set of properties I need is so big that loading the meta_data would be more or less the same overhead as loading the objects.
And even if I _should_ use Python, then it should at least be supported in PythonMethods.
PythonMethods have no more access than DTML Methods/Documents (by design).
And this is correct, IMHO. []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux --- http://www.debian.org Brazil of Darkness -- http://zope.gf.com.br/BroDar
On Thu, 24 Feb 2000, Tres Seaver wrote:
Agreed. filter() is particularly nice, as it eliminates the nesting of the <dtml-if> inside the <dtml-in>. For instance, to grab all contained objects which have a "browseable" property, set to true:
<dtml-in "_.filter( lambda x: x.hasattr( 'browseable' ) and x.browseabe, objectValues() )">
True, but it an be easily accomplished with an external method in your acquisition path. I actually have a bunch of such utlities ... For instance you can have an external method like (untested): def filter(self,seq,val): '''Return elements in sequence (seq) which have an attribute val and it is true''' return filter(lambda x,s=seq,v=val: x.hasattr(v) and getattr(x,v),s) and call it from DTML like: <dtml-in "filter(objectValues(),'browsable')"> simple and IMO more elegant than even having it in the _. Actually we could create a number of generalised utilities and post it somehwere so anybody can download the file and use them. As always security/ safety are concerns ... Pavlos
participants (3)
-
Lalo Martins -
Pavlos Christoforou -
Tres Seaver