Scenario: I have a GUF based authentication system that uses a SQL database to store user profiles. The primary key of the user table is a serial number, so my users can change there username anytime without throwing the tables into a mess, but usernames are otherwise used as a unique ID for a user, so I need to do a name to user_id lookup before doing most queries. I've also got it set up to handle different password hash methods so I can migrate to a new one if the present one sucks - to make this easy I've got a DTML method called encodePassword that takes a password and the (typically acquired) pwd_format property and gets the appropriate external method to turn it into the password hash. So in my password change report I want to do something like this: (name and new_password arrive from the request, pwd_format is an acquired default) <dtml-call "sql_change_password( user_id=sql_get_user_id(name=name), password=encodePassword(password=new_password), pwd_format=pwd_format )"> But I can't because Zope throws a fit about infinite recursion. Bummer. Ok, how about this: <dtml-let password="encodePassword(password=new_password)" user_id="sql_get_user_id(name=name)"> <dtml-call "sql_change_password( user_id=user_id, password=password, pwd_format=pwd_format)"> </dtml-let> That doesn't work either. It seems that when I pass arguments to the method encodePassword, it ceases to acquire anything else from the environment, including my default pwd_format value, and all the external methods that live in the same folder. This is a pain. No arguments, it acquires, give it arguments, it doesn't. If I wanted it to not acquire things from the environment I'd use the <dtml-with ... only> container, but someone has made that call it seems. So how do I supply a method with an argument and tell it to look in it's folder for other properties and methods to acquire? Am I forever doomed to wrap annoying <dtml-let> containers around all of the methods that I want to acquire properties from the rest of Zope? John.