> That is probably the problem. If you're calling another run-mode directly > (as opposed to the run-mode being called via an HTTP request) the cookie you > created has not yet been sent to the web browser. That won't happen until > run_mode_2() is done. This has caused me problems on multiple platforms, because it's avast pain to have to set a value in two places (the cookies to be set and the values that are set byu the cookies you read) throughout your code. My current solution is suprisingly easy, so I'm passing it to the rest of the list. All my apps are subclasses of a subclass of CGI app. This module addes a few helpful routines, includes some wrappers to Template Toolkit, etc. In particularly, it has my eat() and bake() routines. eat() just snags all the passed cookies, and sets an internal hash with their names and values, as well as setting the name of the same params to those values. [I plan to allow you to pass a hash giving alternate names, but I haven't needed it yet]. If, however, bake() has been called on any of those values, it does nothing with that value. bake() sets an internal hash with the name and value of the passed param names. my template calling routine uses that hash to set all cookies via header_props when the time comes. Thus, dealing with any values that are altered by cookies is nice and easy -- any routine that needs the value simply calls eat() -- and the param is either set to the cookie'd value, or let alone as appropriate. Any value I want to set I just call bake() on, and it will be set at the right time. -- SwiftOne suppressed --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/suppressed/ To unsubscribe, e-mail: suppressed For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.