You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2004/01/15 17:22:49 UTC
load_response.tcl
> From: brad@apache.org
> Subject: cvs commit: tcl-rivet/rivet/rivet-tcl load_response.tcl
> To: tcl-rivet-cvs@apache.org
> Date: 15 Jan 2004 16:05:48 -0000
> Changed behavior from appending discovered values to existing
> elements in the response array to simple assignment.
> diff -u -r1.2 -r1.3
> --- load_response.tcl 11 Mar 2002 22:54:42 -0000 1.2
> +++ load_response.tcl 15 Jan 2004 16:05:48 -0000 1.3
> @@ -9,10 +9,6 @@
> upvar 1 $arrayName response
>
> foreach {var elem} [var all] {
> - if {[info exists response($var)]} {
> - lappend response($var) $elem
> - } else {
> - set response($var) $elem
> - }
> + set response($var) $elem
> }
> }
Hi Brad - can you comment on this code some? My recollection is that
[var all] has the potential to return multiple values for one CGI
variable... Changing this might break for people depending on that.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Andy Doerr <an...@swbell.net>.
I usually do not preload data, but I like to override the data in the
response
#overly simplified example
load_response
if {[info exists response(save_checkbox)]} {
set $response(mode) "write"
}
brad@sc.com wrote:
> Damon Courtney <da...@your.unreality.com> asserted:
>
>
>> It's not meant to BE run more than once. At least not on the same
>>array.
>
>
> Hrm, didn't find that in the documentation. :-)
>
> I think that this is the crux of the biscuit: there's no way to not call it
> more
> than once on any array *except* response.
>
> I thought the response array was some sacred representation of what the user
> just clicked (and I'm willing to give it up like a superstition). If it's going
> to contain defaults, too, maybe it should be named call_and_response, loaded by
> calling overload_response?
>
> Could there be a switch to determine the behavior?
>
> Who else is using response to store non-user-response data? Am I the only one
> who isn't?
>
>
>>Believe me, I wrote NWS for a long, long time, and I ran into this issue
>>many times. But, as much as I wanted to fix it internally, it's not a bug.
>>I needed to fix my code so that I wasn't calling it multiple times.
>>
>>
>>>That's a valid point, but I think it's also definitely wrong for you
>>>to get different arrays from different calls to load_response, too...
>>
>> How many times do you need to load the response? Once. Any more than
>>that, and you're just wasting cycles.
>
>
> What about procs that need values that have been set by the user since the last
> load_response?
>
>
>> If you add the unset, you have
>>limited what the programmer can do.
>
>
> The programmer is free to define data structures to his/her heart's content.
> The
> programmer is not stuck with, say, the response array to store pertinent data.
> Why not use a different array and let response just be the... response?
>
>
>>If you don't have the unset, it's
>>the programmer's responsibility to unset the array before they call the
>>proc again. Which is better?
>
>
> It depends on the context. I don't like doing set up before invoking a loop to
> traverse the response array, and then to clean up after it. It's far less code
> (for me) to treat the response array as read-only.
>
> So we have different programming styles. No problem. You need load_response to
> do the append. Cool. I'll write my own that does what I need. I'm not married
> to the Rivet source modification, but I need the functionality given by the
> mod.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Karl Lehenbauer <ka...@sc.com>.
We can definitely find and fix where we're calling load_response twice.
However, we've had to debug it twice and both times it appeared as
strange malfunctions that cast suspicion on various pieces of our stuff
quite distant from load_response.
How about if it retains its old functionality but we make it an error
to call it twice? I've been coding explicit calls to error a lot more
in places where I would in the past have just let the code fail, and
load_response is a perfect example, and it sure helps cut down on the
debugging.
On Jan 16, 2004, at 3:25 AM, David N. Welton wrote:
>
> *) If someone happened to use load_response more than once, getting
> different answers is surprising.
>
> *) I think that if you want to merge arrays, or have one act as a
> default that gets overridden, it might be best to do that
> explicitly in a merge_arrays function. That way, each proc does
> only one thing.
>
> *) If load_response has always worked the way it has in NWS, I don't
> want to mess with it - it would be better to create a new function.
>
> *) Whatever we do, it ought to be documented better so that we can say
> "I told you so!" and point to the docs, at the very least:-)
>
> *) Even better would be to write some test cases as well.
>
> --
> David N. Welton
> Consulting: http://www.dedasys.com/
> Personal: http://www.dedasys.com/davidw/
> Free Software: http://www.dedasys.com/freesoftware/
> Apache Tcl: http://tcl.apache.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by "David N. Welton" <da...@dedasys.com>.
> I think we should do what we did with NWS and swipe all the
> manpage docs created by the Tcl core team upon release and include
> them with our docs. That way someone completely new to Tcl and
> Rivet has all the docs for all the commands in one place.
> This worked very well for NWS when trying to point someone in
> the direction of really helpful docs. That, and it makes it looks
> like we have really thorough documentation, when in fact, we just
> took what was already there and made it part of our release.
> At the very least, we should put it on the Rivet site in the
> docs. We don't have to include it all with our release if you don't
> want to.
I think including all those docs directly is a bit much, myself.
Maybe we could have a link to the Tcl docs in the header or footer of
each doc page, or someplace else really blatant?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl - vote?
Posted by Andy Doerr <an...@swbell.net>.
Leave it as it is (unset the array)
Documentation should reflect that it will clear any values already existing?
David N. Welton wrote:
> I want to be clear: leave it like it *was* or like it *is? The
> version currently in CVS does unset the array.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl - vote?
Posted by "David N. Welton" <da...@dedasys.com>.
I want to be clear: leave it like it *was* or like it *is? The
version currently in CVS does unset the array.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl - vote?
Posted by Andy Doerr <an...@swbell.net>.
I agree, leave it as it is.
Damon Courtney wrote:
>>Should we have a vote on what to do about load_response? We have
>>several options:
>>
>>1) Leave it like it was.
>>
>>2) Leave the current version which unsets the array.
>>
>>3) Do not unset the array, but raise an error if it is called a second
>> time.
>>
>>I prefer these in the order 2, 3, 1, but I could be convinced that #3
>>is right if there is a lot of NWS code that #2 would break.
>
>
> Leave it as it is now. I think it's the best solution.
>
> D
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl - vote?
Posted by Damon Courtney <da...@your.unreality.com>.
> Should we have a vote on what to do about load_response? We have
> several options:
>
> 1) Leave it like it was.
>
> 2) Leave the current version which unsets the array.
>
> 3) Do not unset the array, but raise an error if it is called a second
> time.
>
> I prefer these in the order 2, 3, 1, but I could be convinced that #3
> is right if there is a lot of NWS code that #2 would break.
Leave it as it is now. I think it's the best solution.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl - vote?
Posted by "David N. Welton" <da...@dedasys.com>.
Hi,
Should we have a vote on what to do about load_response? We have
several options:
1) Leave it like it was.
2) Leave the current version which unsets the array.
3) Do not unset the array, but raise an error if it is called a second
time.
I prefer these in the order 2, 3, 1, but I could be convinced that #3
is right if there is a lot of NWS code that #2 would break.
Thanks,
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Damon Courtney <da...@your.unreality.com>.
> I produced virtually all of the .xml doc myself, and could really use
> comments or suggestions. It gets difficult to document something you
> know intimately because you forget what people need to know about it!
>
> So, please do comment on specific bits that could be improved, but
> also suggest how they could be improved, what needs to be added. I'm
> looking forward to some collaboration with this:-)
I think we should do what we did with NWS and swipe all the manpage
docs created by the Tcl core team upon release and include them with our
docs. That way someone completely new to Tcl and Rivet has all the docs
for all the commands in one place.
This worked very well for NWS when trying to point someone in the
direction of really helpful docs. That, and it makes it looks like we
have really thorough documentation, when in fact, we just took what was
already there and made it part of our release.
At the very least, we should put it on the Rivet site in the docs.
We don't have to include it all with our release if you don't want to.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by "David N. Welton" <da...@dedasys.com>.
brad@sc.com writes:
> "David N. Welton" <da...@dedasys.com> hinted that:
> Name
> load_response � load form variables into an array.
> Synopsis
> load_response arrayName
> Description
> Load any form variables passed to this page into an array.
> I love the man page style (maybe these exist as nroff, somewhere). I
> love the web-man-page style. It's just that these entries don't have
> nearly enough information for a developer. I'd like to do this one
> and have you on the list critique it. I want something like the
> entries in section 2 or 3 of the UNIX manual... I'll show you later
> today.
I produced virtually all of the .xml doc myself, and could really use
comments or suggestions. It gets difficult to document something you
know intimately because you forget what people need to know about it!
So, please do comment on specific bits that could be improved, but
also suggest how they could be improved, what needs to be added. I'm
looking forward to some collaboration with this:-)
Thanks,
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Andy Doerr <an...@swbell.net>.
I kind of liked the switch idea to retain previous data, but I do not
think I have ever used load_response in that way.
Damon Courtney wrote:
> You know what? I'm over it. Leave it as it stands with David's last
> commit. I still want the append capability, but it SHOULD probably produce
> the same results anytime you execute it. I've always used it thusly:
>
> load_response
>
> if {![info exists response(foo)]} { set response(foo) }
>
> Anyway. So, I don't really care if it gets blown away. I call it once
> at the very top of my program, and it never gets called again. Just make
> sure your new docs point out that the array is unset and restored to a
> pristine state everytime the command is called. At least it'll be clear
> to some other poor sod. 0-]
>
> D
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by br...@sc.com.
Damon Courtney <da...@your.unreality.com>:
> I think this is the problem. It's not that we don't want good docs,
> we just haven't written them yet. 0-] I did my best to document most of
> DIO at the time I put it into the code... Since then, my uh, docs, have
> become a little lax. It's no one's fault but my own.
I know somebody else that does that. I just saw him this morning, first thing.
Right after I stepped on the cat, there he was, staring at me from the mirror.
That bastard. :)
> I think Rivet has one major advantage over PHP in terms of users.
> It's much easier to learn.
Hear, hear.
> At least from the standpoint of the average,
> non-programmer web developer. TCL has a syntax that is easier to grasp
> for a lot of people. Those who are programmers just bitch about white-
> space-delimited languages, nyah, nyah, nyah. But, without decent docs
> (which we're all aware that we're seriously lacking), Rivet might as
> well be just as hard as any other language.
Well, what do we want? More online man-page style stuff? I like that, given the
hyperlink potential for SEE ALSO and other man-page-style sections.
I also think that in the "easier to learn" category it would be very useful for
neophytes to have a "how it works" tutorial, even if we just link to someone
else's work.
> Anyway. So, I don't really care if it gets blown away. I call it once
> at the very top of my program, and it never gets called again.
I finally understand what you were saying with the "call it once" phrase.
I have some stuff that POSTs forward several times, i.e., user fills out a form,
submits, and then I may need to present him/her with another form. I had
thought that load_response was something I had to do at the beginning of any
proc that counted on form input from the caller.
> Just make
> sure your new docs point out that the array is unset and restored to a
> pristine state everytime the command is called. At least it'll be clear
> to some other poor sod. 0-]
Right, and that's what has me think I'm the guy for a documentation pass. I
haven't learnt Rivet, yet. :_)
--
"Grep sed "awk! man cut grep, edit banner false! get help!" Man disable
grep, split banner, join prof admin. Grep mount eqn, find path. Grep
echo spell. False cat kill admin, man. Grep find banner, make true message."
-- J. Eric Townsend, 80s UNIX hacker, 90s Burning Man Art Car Creator, 00s
anarchist
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Damon Courtney <da...@your.unreality.com>.
> That's been my main beef with Rivet--and with NWS, come to think of it.
>
> The Rivet docs seem to assume that the reader knows something. I'm not saying
> they should include a "So You Want To Be A Web Developer" section, but we could
> at least refer to other docs.
>
> In particular, the fifteen commands documented at
> http://tcl.apache.org/rivet/html/commands.en.html are just too brief. I know, I
> know, why does anyone even need docs when they have the source code? Maybe this
> is their first Tcl experience. Maybe this is their first foray into Apache,
> even. I don't know why, I just want it that way. For example:
>
> And I totally understand how it feels to have something done (finally!) and
> then
> face the docs. No one is wrong for how the docs are. I probably don't even know
> about all of the docs. I do think there's room for improvement.
I think this is the problem. It's not that we don't want good docs,
we just haven't written them yet. 0-] I did my best to document most of
DIO at the time I put it into the code... Since then, my uh, docs, have
become a little lax. It's no one's fault but my own.
I think we all (as programmers) just get into having fun writing the
code and forget that there's a world out there that doesn't know everything
we know. Our docs do make a lot of assumptions that people are experienced.
And that's probably a bad thing for software that would like to compete with
something like PHP.
I think Rivet has one major advantage over PHP in terms of users.
It's much easier to learn. At least from the standpoint of the average,
non-programmer web developer. TCL has a syntax that is easier to grasp
for a lot of people. Those who are programmers just bitch about white-
space-delimited languages, nyah, nyah, nyah. But, without decent docs
(which we're all aware that we're seriously lacking), Rivet might as
well be just as hard as any other language.
> So, what shall we do with load_response? I naively committed a change that no
> one but me likes. Do you guys want to roll back? I need to know for the
> documentation. :-)
You know what? I'm over it. Leave it as it stands with David's last
commit. I still want the append capability, but it SHOULD probably produce
the same results anytime you execute it. I've always used it thusly:
load_response
if {![info exists response(foo)]} { set response(foo) }
Anyway. So, I don't really care if it gets blown away. I call it once
at the very top of my program, and it never gets called again. Just make
sure your new docs point out that the array is unset and restored to a
pristine state everytime the command is called. At least it'll be clear
to some other poor sod. 0-]
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by br...@sc.com.
"David N. Welton" <da...@dedasys.com> hinted that:
> Whatever we do, it ought to be documented better
That's been my main beef with Rivet--and with NWS, come to think of it.
The Rivet docs seem to assume that the reader knows something. I'm not saying
they should include a "So You Want To Be A Web Developer" section, but we could
at least refer to other docs.
In particular, the fifteen commands documented at
http://tcl.apache.org/rivet/html/commands.en.html are just too brief. I know, I
know, why does anyone even need docs when they have the source code? Maybe this
is their first Tcl experience. Maybe this is their first foray into Apache,
even. I don't know why, I just want it that way. For example:
Name
load_response load form variables into an array.
Synopsis
load_response arrayName
Description
Load any form variables passed to this page into an array.
I love the man page style (maybe these exist as nroff, somewhere). I love the
web-man-page style. It's just that these entries don't have nearly enough
information for a developer. I'd like to do this one and have you on the list
critique it. I want something like the entries in section 2 or 3 of the UNIX
manual... I'll show you later today.
And I totally understand how it feels to have something done (finally!) and
then
face the docs. No one is wrong for how the docs are. I probably don't even know
about all of the docs. I do think there's room for improvement.
Regarding NWS: I thought it was so incredibly cool, but all the online docs
were
for 3.3, but all I could find to run was 2.x. It gave it this Estes Model Rocket
feel (substitute your own docs-don't-match-the-code experience here).
So, what shall we do with load_response? I naively committed a change that no
one but me likes. Do you guys want to roll back? I need to know for the
documentation. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by "David N. Welton" <da...@dedasys.com>.
*) If someone happened to use load_response more than once, getting
different answers is surprising.
*) I think that if you want to merge arrays, or have one act as a
default that gets overridden, it might be best to do that
explicitly in a merge_arrays function. That way, each proc does
only one thing.
*) If load_response has always worked the way it has in NWS, I don't
want to mess with it - it would be better to create a new function.
*) Whatever we do, it ought to be documented better so that we can say
"I told you so!" and point to the docs, at the very least:-)
*) Even better would be to write some test cases as well.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Damon Courtney <da...@your.unreality.com>.
> I think that this is the crux of the biscuit: there's no way to not call it
> more
> than once on any array *except* response.
>
> I thought the response array was some sacred representation of what the user
> just clicked (and I'm willing to give it up like a superstition). If it's going
> to contain defaults, too, maybe it should be named call_and_response, loaded by
> calling overload_response?
>
> Could there be a switch to determine the behavior?
>
> Who else is using response to store non-user-response data? Am I the only one
> who isn't?
response is the name chosen historically by NeoWebScript. You can
pass any array name you want to the load_response command. It just defaults
to response as a convenience.
> What about procs that need values that have been set by the user since the last
> load_response?
The user or the developer? The user can't set values since the last
load_response since the QUERY_STRING only changed with a new page load.
> The programmer is free to define data structures to his/her heart's content.
> The
> programmer is not stuck with, say, the response array to store pertinent data.
> Why not use a different array and let response just be the... response?
Yes, but why can't I initialize a little data for the sake of brevity
if I want to? IE:
set response(use_clicked_check_box) 0
load_response
In Rivet, if the user didn't click the checkbox, it doesn't exist in
the subsequent page response. Or, what if I'm writing an interface that
has both an admin and user interface but share the same proc. Each could
pass its own variable through the form leaving some existing and others
not. So, I can do:
set response(user_name) ""
load_response
If the user_name was passed, it will overwrite my value. If not, it
will stand as an empty string. Then, I can use it through my proc as
I please.
> It depends on the context. I don't like doing set up before invoking a loop to
> traverse the response array, and then to clean up after it. It's far less code
> (for me) to treat the response array as read-only.
>
> So we have different programming styles. No problem. You need load_response to
> do the append. Cool. I'll write my own that does what I need. I'm not married
> to the Rivet source modification, but I need the functionality given by the
> mod.
If you treat the array as read-only then why the need at all to call
load_response more than once? Calling it once and never modifying it
(treating it as read-only), you should never need to call load_response
again. The data hasn't changed at all. It can't change until they reload
the page or click forward, at which time the load_response would rebuild
the data.
You can certainly write your own proc. The load_response is a
convenience I stole from NWS. David would prefer everyone use the 'var'
command anyway. 0-] I just don't see the need to ever call load_response
more than once unless you have code that is modifying the response array.
If you never modify it, it never changes.
Damon
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by br...@sc.com.
Damon Courtney <da...@your.unreality.com> asserted:
> It's not meant to BE run more than once. At least not on the same
> array.
Hrm, didn't find that in the documentation. :-)
I think that this is the crux of the biscuit: there's no way to not call it
more
than once on any array *except* response.
I thought the response array was some sacred representation of what the user
just clicked (and I'm willing to give it up like a superstition). If it's going
to contain defaults, too, maybe it should be named call_and_response, loaded by
calling overload_response?
Could there be a switch to determine the behavior?
Who else is using response to store non-user-response data? Am I the only one
who isn't?
> Believe me, I wrote NWS for a long, long time, and I ran into this issue
> many times. But, as much as I wanted to fix it internally, it's not a bug.
> I needed to fix my code so that I wasn't calling it multiple times.
>
> > That's a valid point, but I think it's also definitely wrong for you
> > to get different arrays from different calls to load_response, too...
>
> How many times do you need to load the response? Once. Any more than
> that, and you're just wasting cycles.
What about procs that need values that have been set by the user since the last
load_response?
> If you add the unset, you have
> limited what the programmer can do.
The programmer is free to define data structures to his/her heart's content.
The
programmer is not stuck with, say, the response array to store pertinent data.
Why not use a different array and let response just be the... response?
> If you don't have the unset, it's
> the programmer's responsibility to unset the array before they call the
> proc again. Which is better?
It depends on the context. I don't like doing set up before invoking a loop to
traverse the response array, and then to clean up after it. It's far less code
(for me) to treat the response array as read-only.
So we have different programming styles. No problem. You need load_response to
do the append. Cool. I'll write my own that does what I need. I'm not married
to the Rivet source modification, but I need the functionality given by the
mod.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Damon Courtney <da...@your.unreality.com>.
> If you run the following code multiple times, with the commented out
> array set, it will keep appending stuff.
It's not meant to BE run more than once. At least not on the same array.
Believe me, I wrote NWS for a long, long time, and I ran into this issue
many times. But, as much as I wanted to fix it internally, it's not a bug.
I needed to fix my code so that I wasn't calling it multiple times.
> That's a valid point, but I think it's also definitely wrong for you
> to get different arrays from different calls to load_response, too...
How many times do you need to load the response? Once. Any more than
that, and you're just wasting cycles. If you add the unset, you have
limited what the programmer can do. If you don't have the unset, it's
the programmer's responsibility to unset the array before they call the
proc again. Which is better?
> And as long as we're at it,
>
> set response($var) [list $response($var) $elem]
>
> seems better to me than
>
> lappend response($var) $elem
>
> because it fixes up the first one - or is there a reason behind that
> too?
This was the right thing to do. Good catch on that. 0-]
Damon
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> Problem is, it's not a bug. load_response was taken from
> NeoWebScript with almost the same functionality that NWS had. The
> reason we did an lappend instead of just a set is that in HTML, it
> is legal to have checkboxes with all the same name. In the case of
> that, load_response will append a list of all the checkboxes that
> were checked in the last screen.
Yes, yes, I know this part:-) The problem was this:
If you run the following code multiple times, with the commented out
array set, it will keep appending stuff.
proc load_response {{arrayName response}} {
upvar 1 $arrayName response
#array set response {}
foreach {var elem} [var all] {
if {[info exists response($var)]} {
set response($var) [list $response($var) $elem]
} else {
set response($var) $elem
}
}
}
> And, personally, I don't think load_response should unset the
> array. What if I want to setup some defaults in response and then
> have load_response overload them? I can't now. Unsetting should
> always be the responsibility of the programmer unless we're talking
> about a loop.
That's a valid point, but I think it's also definitely wrong for you
to get different arrays from different calls to load_response, too...
> *shrug* Just my thoughts on the matter. I don't have the best
> solution. Just the reasoning behind its current function.
Anyone else care to comment?
And as long as we're at it,
set response($var) [list $response($var) $elem]
seems better to me than
lappend response($var) $elem
because it fixes up the first one - or is there a reason behind that
too?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by Damon Courtney <da...@your.unreality.com>.
> Some private discussions with Brad led us to the root of the problem -
> the 'response' array needs zeroing after each time load_response is
> called, so as to not keep adding stuff to the array element if
> load_response is called multiple times.
>
> proc load_response {{arrayName response}} {
> upvar 1 $arrayName response
>
> array set response {}
>
> foreach {var elem} [var all] {
> if {[info exists response($var)]} {
> set response($var) [list $response($var) $elem]
> } else {
> set response($var) $elem
> }
> }
> }
>
> In addition, I also fixed things so that the element looks like this:
>
> response(x) = {this is comment 1} {this is comment 3}
>
> with two values, whereas previously it was:
>
> response(x) = this is comment 1 {this is comment 3}
>
> So, good stuff - thanks to Brad for catching the bug!
Problem is, it's not a bug. load_response was taken from NeoWebScript
with almost the same functionality that NWS had. The reason we did an
lappend instead of just a set is that in HTML, it is legal to have
checkboxes with all the same name. In the case of that, load_response
will append a list of all the checkboxes that were checked in the last
screen.
And, personally, I don't think load_response should unset the array.
What if I want to setup some defaults in response and then have load_response
overload them? I can't now. Unsetting should always be the responsibility
of the programmer unless we're talking about a loop.
*shrug* Just my thoughts on the matter. I don't have the best solution.
Just the reasoning behind its current function.
Damon
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: load_response.tcl
Posted by "David N. Welton" <da...@dedasys.com>.
Some private discussions with Brad led us to the root of the problem -
the 'response' array needs zeroing after each time load_response is
called, so as to not keep adding stuff to the array element if
load_response is called multiple times.
proc load_response {{arrayName response}} {
upvar 1 $arrayName response
array set response {}
foreach {var elem} [var all] {
if {[info exists response($var)]} {
set response($var) [list $response($var) $elem]
} else {
set response($var) $elem
}
}
}
In addition, I also fixed things so that the element looks like this:
response(x) = {this is comment 1} {this is comment 3}
with two values, whereas previously it was:
response(x) = this is comment 1 {this is comment 3}
So, good stuff - thanks to Brad for catching the bug!
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org