Hi Casey, Casey Duncan wrote:
- In my ZPT, I'm using "user/getUserName", which works perfectly.
- I'd now like to migrate this functionality to a Formulator form
...[snip]...
Probably Formulator does not supply the global "user" like ZPT does. You might have to resort to:
python:modules['AccessControl'].getSecurityManager().getUser().getUserN ame()
But that assumes that Formulator supplies "module" which it may not.
It didn't...
create a python script called "getUserName" which contains the code:
from AccessControl import getSecurityManager return getSecurityManager().getUser().getUserName()
Then use: here/getUserName as the path expression (assuming Formulator uses "here"). As you can see Products are free to create whatever variable bindings they like for their TALES expressions.
...but this worked fine, and better yet is intelligible to me, even in my brain-charred state. So, my impression that Formulator does not let me use the same expressions seems to be correct - and it was this inability to use the global variables and syntax indicated in the TALES documentation which was throwing me. The moral of the story seems to be to break the problem down into chunks - a script which carries the appropriate expression (and can be tested in isolation) and a TALES expression which does no more than call the script (and is therefore v. simple). I'd hoped I could hold all the derivations of values /inside/ the Formulator form, but that seems to have two costs - one that it doesn't work (!), the other that the error messages are from the "dumb insolence" family... Thanks, Casey - I feel a bit more empowered and a lot less frustrated now! -- Regards, PhilK Email: phil@xfr.co.uk / Voicemail & Facsimile: 07092 070518 “The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words.” Philip K. Dick