Valerio Gionco <[EMAIL PROTECTED]> writes:
> 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.
Well the problem is then with accessing specific variables, no? You
basically have to transform an array like this in something useful. I
really want to try and arrive at a general solution that presents the
script writer with data that is already easy to use. They shouldn't
have to do processing on it.
I'm not opposed to making this available, for those who want 'lower
level' access like this, though.
> 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).
I am willing to break backwards compabitility if it is very
beneficial. I would rather see things done right, while the user base
is still small.
> > 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' ????"....
Yeah, I'm not really interested in putting something like that in.
Also, should you want to search on it, 'p' is difficult, as you'll
come up with tons of them that aren't what you are looking for.
> 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
Ok, but you have to put that in an array to get a specific value out
that you know should be there.
> The best solution I've found is still the use of two variables: the
> array ::request::VARS for the variables and the list
> ::request::VARSLISTS for the variable names assigned more than a
> time (like I suggested with last email).
Maybe we can do a couple of things.... the solution above seems like a
good compromise that will work with existing scripts.
We could also create a command that does all the extra things we want,
precisely how we want.
set VARSL [vars list]
set foo [vars get foo]
set foo [vars get -array foo]
or any number of things like that, I suppose.
--
David N. Welton
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
Work: http://www.innominate.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
