On Mon, May 29, 2000 at 04:33:20PM -0300, Lalo Martins wrote:

One big question is: what's wrong with filter, map and lambda? They can make a lot of code a lot simpler, specially for people who have a background in functional programming.

IIRC there is nothing wrong with them - only that all builtins were disabled and some specific few were re-enabled, and then those three were overlooked.

Count one vote for getting them back (_.lambda, _.filter, _.map is fine enough, of course).

I can't comment with authority on why these methods are not accessible, but I imagine that they are banned because they'll probably let you lock up Zope in one way or another, creating a convenient denial-of-service attack. What I would like to say is that if your application needs lambda, filter or map, your code is getting bejond report or presentation generation (for which DTML is intended) and in the realm of data manipulation and business rules. In this case your code would be much better placed in some form of Method object, be that an External, Python, or when ready, Perl Method, or even as a disk based Product. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------

...

What I would like to say is that if your application needs lambda, filter or map, your code is getting bejond report or presentation generation (for which DTML is intended) and in the realm of data manipulation and business rules. In this case your code would be much better placed in some form of Method object, be that an External, Python, or when ready, Perl Method, or even as a disk based Product.

1: This is simply not true, and a very poor excuse for handicapping the language.

Nope. Lamba, filter, reduce, and map should IMHO not be part of DTML. Actually, exprs probably shouldn't be in there in the first place. People are trying to use DTML as a way to process non-UI elements. This is a slippery slope, and leads to something like PHP or ASP. My opinion is this: Generate and format your HTML with DTML, and do everything else in Python. This gives you the added benefit that you can change the return values of functions by changing the Python code without having to muck with DTML, which is painful any way you look at it. People are right when they say DTML is beginning to get worse than Perl, and IMHO, adding these functions could make it even worse than it is now. This sort of processing was not meant to happen in an expr under Zope. Python lets you do it, but it's sort of hard for somebody else to understand after you've completed it, even if they know Python well. Functional constructs are handy, but not the most clear thing on the planet.

A common example is:

<dtml-in "_.map (lambda item: Catalog.getobject (item.data_record_id_), Catalog (REQUEST)">

How could someone understand this when you're finished with it? I looked at it three times before figuring out what you were trying to do. What if you didn't write it and you needed to answer somebody asking a question about it on this mailing list? Isn't this much more understandable as an external method explicitly? def return_cataloged_objects(self): obs = [] catalog = self.Catalog request = self.REQUEST for r in catalog(request): d_rid = r.data_record_id_ ob = catalog.getobject(d_rid) obs.append(ob) return obs then: <dtml-in return_cataloged_objects> ... </dtml-in> It *might* be slighly slower, but someone maintaining your code will eventually thank you for this. Eventually it will cost you less money somewhere that you might be able to buy a faster server with.

I know fetching the actual records from a ZCatalog introduces a performance penalty, but sometimes it's necessary; there are times you need to be absolutely sure everything is pushed on the namespace, including user-defined properties and sub-objects. This is the case in Hack&Roll, and I have to use a very ugly Python Method there (and as PythonMethods don't have map either, I have to build a list from scratch using for, which introduces additional penalties as I'm basically bypassing Python's optimizations).

Sometimes. Sometimes not. Read http://www.python.org/doc/essays/list2str.html . As I understand it, by using expr syntax to begin with, you're defeating some of Zope's caching mechanisms, actually slowing things down in reality.

2: If I should be using a Python Method, then Python Methods should have these forms, and they don't.

Maybe they should... it would be nice. I'm not sure why they're not in Python Methods, other than Evan tried to make the security inherent in Python methods as close to DTML as he could. I use map a lot. I don't use lambda unless I really, really have to. Reduce and filter.. eh. I dunno. They're sort of on the periphery of usefulness.

3: In short, these excuses are just the fallback (or should I say Acquired?) excuses used mostly by people who don't know how to use these very cool features of Python.

I would hardly say Martijn is one of those. :-)

Lalo Martins wrote:

...

How could someone understand this when you're finished with it?

Perfectly clearly for anyone used to functional programming; I'd even say, clear on first sight. A lot easier to understand and maintain than a separate method.

OK, I give. I think this would be fine in a Python (or external) method. But I don't share your opinion that it should be exposed in DTML.

...

Isn't this much more understandable as an external method explicitly?

No. And external methods should definitely be phased out as much as possible, they defeat one of the major advantages of Zope (everything is manageable trought the web).

Agreed on the point about external methods. Python methods should succeed them. And if they do succeed them, I would like to see the functional built-ins exposed. It would be a shame to not have them if their use doesn't impact security.

Your method, in particular, is worse to understand than my one-liner, specially for anyone who uses functional programming seriously; but even other people would have to reason for a few minutes to understand what you're appending to that poor list and why.

I can see that argument... it depends on the reader, I suppose. I wouldn't complain much actually if the Python code had functional stuff in it. It's having it in DTML that bugs me, for reasons that have to do with separating HTML-like stuff from the stuff that actually runs the site under the hood.

...

Maybe they should... it would be nice. I'm not sure why they're not in Python Methods, other than Evan tried to make the security inherent in Python methods as close to DTML as he could. I use map a lot. I don't use lambda unless I really, really have to. Reduce and filter.. eh. I dunno. They're sort of on the periphery of usefulness.

I respect the fact that you have your opinion where DTML is going and where it should go and where it shouldn't. But I don't think it is an excuse to cripple it. It is, instead, your opinion, as much as mine is mine.

Yes, expressions make DTML less clear and walk around caching.

No, they shouldn't be banned. They're useful. Ban them and all you get is either a code fork or a considerable number of lost users.

I didn't say that we should ban them, I said they shouldn't have been introduced in the first place. We can't ban them now, we know that.

You compare these to ASP, PHP or Perl. I compare them to __getattr__, __getitem__, __call__ and others on Python, and to operator overloading in C++.

I compare them to ASP and PHP (not perl.. maybe embperl or PerlScript, but not perl), because these are languages that encourage the use of so-called "business logic" inside HTML, along with so-called "presentation logic". Whatever you name them, I like to keep them as separate as possible so designers don't shirk in fear or mess things up when they need to navigate around hairy constructs in code. I've found that separating them also lets you shift UI elements more easily. It's clear that you don't share my opinion, nor do the other 99 million people who use ASP or PHP. But I'm on the more moderate side of things, believe it or not...you should really talk to some other folks here, you'd argue for hours. :-)

I want to install Zope in multiple instances. Apparently if you provide a unique name and user names you can do this. My question is...., "How would you gain access to each individual Zope?" For instance, I would like "manager 1" to have access to "Zope 1" on port:8080. He will use Zope in tandem with his static web. I then want "manager 2" to have access to "Zope 2" in the same capacity as "manager 1." They will also use thier own separate product preferences. I want to set-up some fellow newbie types to share the Zope Road to Enlightenment with. What I don't understand from the install.txt and the "how to" is just how each manager is going to access the correct Zope. They each have a static webspace via a web server on port:80. I am not concerned right now about .pcgi, frontend and backend servers, but separating and accessing two standard installs of Zope on an NT server. I am a bit embarrased asking this because I did have this scenario working via pcgi. I got distracted for a couple of weeks and cannot reproduce it. So I want to do it again with straight installs, then .pcgi and later fool around with employing Site Access. Hope I've provided enough info...and that the answer is not too time consuming to return. Thanks, hisnibs Virginia Web http://www.virginiaweb.com hisnibs@ihosts.net