Wojciech Kocjan wrote:
> I think David should also consider a function to return
> QUERY_STRING in a name-value list (suitable for array set) - like
> script.dtcl?a=b&c=d&e=f -> {a b c d e f}. That way it could be used to
> fetch any data w/o involving sublists... Simple
> 'foreach {n v} [hargs] { hputs "$n=$v<BR>\n" }' would do.
This could be a good solution, too, if we don't care about replicating
all variables in two places. (we must put values in VARS too, to
keep compatibility with old scripts).
>
> ps. I also vote for alias 'p' to 'hputs' in the core - to use <?p $var ?>
> (a bit similar to AOL's <%=$var%> :-). I use it for 2 weeks
> (proc p {args} {eval hputs $args} ;-) and it's great help. Also, since
> stuff outside <? ?> is parsed to hputs "string", it could be put directly
> in that hputs statement. And it would be wonderful is it could be shorted
> to <?p$var?> - a bit obfuscated perhaps, but I like small code ;-).
....hmmmm...I see myself reading my own code within a year or so and
asking "what the #�$%& are all those 'p' ????"....
Anyway the name-value list is a very comfortable solution. Since usually
CGI variables are not so many, duplicating them shouldn't hurt too much.
Loking at the source code, I realize that the simpler thing to do would
be simply adding a variable $::request::VARSL; thus the TCL code
becomes
foreach {n v} $::request::VARSL {
hputs "$n=$v<BR>"
}
Valerio Gionco
<[EMAIL PROTECTED]>
--
****************************************************************************
"Life's not fair, but the root password helps."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
