On 15 May 2001, David N. Welton wrote:
> Valerio Gionco <[EMAIL PROTECTED]> writes:
> > > 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.
Processing such stuff is 9 lines away:
proc getarg {key lst} {
set rc [list]
foreach {n v} $lst {
if {$n==$key} {
lappend rc $v
}
}
return $rc
}
> I'm not opposed to making this available, for those who want 'lower
> level' access like this, though.
Well, then do it ;-)
> > 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.
Yeah, that's what Tcl guys have been doing ;-) Just don't break any after
1.0 release... I don't want to see 10 dtcl packages in apt ;-)
> > ....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.
vim page.ttml
/<?p
;-)
Besides, this is an idea taken from AOLserver, which is quite useful. I'm
using it very often, mostly when I want to insert a variable in HTML code.
It's easier to read that way.
But, I'm just giving you people an advice - if you don't like it, don't
implement it :-)
> > 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.
I prefer the above procedure. After putting it in GlobalInit, it's quite
easy to use since I can do:
foreach value [getarg checkbox $VARSL] {
hputs "You checked $value.<BR>"
}
Notice there's no info exists (which AFAIR had some memory leak for
non-existant variables in older Tcl releases - but I'm not quite sure at
the moment).
> > 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.
Yeah, ns_key works great for such solutions.
>
> set VARSL [vars list]
> set foo [vars get foo]
> set foo [vars get -array foo]
>
> or any number of things like that, I suppose.
hputs "You pressed \
[join [vars get -default [list item1 item2 item3 -array foo] ", "]"
That looks nice and adequate to most people's needs :-)
--
Wojtek Kocjan
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
