I quoted some of the arguments brought up on the list almost 4 years ago
because I just wanted to recall the history of the problem.
I personally understand many of your arguments (switches and
nested lists included), therefore I won't answer every single point
of your message.
Let me recall that I have a private copy of load_response in my classes
and it works the way i thought rivet's load_response had to work.
I didn't change the name because I also wanted it to override rivet's proc.
As I said, I had brought up the problem on the list when I was just a user,
only David answered.
I endorse your proposal of having a new procedure with a cleaner
and more rigorous behavior. In principle I also like Feargal's proposal
of having load_response emulate more precisely NWS' load_response
but I don't know what impact would have on existing code.
-- Massimo
P.S. For this list you don't need to resort to nable: the apache
project keeps on the web rivet-dev's archives starting from 2001.
P.P.S I will be unable to answer any message for the next 2 days
Cristian wrote:
On 10/4/07, *Massimo Manghi* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
i suspect the answer depends on what you expect from load_response.
Reading the docs, I should expect the form values to be available in
an array, but see below...
I can understand from the archive is that the debate was not only
about
load_response "per se", but how everyone expected to use it to
suit their
approach to the problem.
Archives in nable didn't go back to 2004... now I found the old
discussions and apparently the main issue in discussion was if
load_response had to reset the response array each time it was called.
This is not the issue we are discussing today.
Citing David from a mail dating from 15 jan 2004,
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}
we can see that the intention is to produce a proper multi valued var
except that the script was tested with only 2 values. If one more
value of x was added to this example I guess they would have fixed
this a long time ago. Nobody said anything because of this change in
the code. What I am proposing is to extend the sought functionality to
"more than 2" valued vars.
A strong point was that load_response is taken from NeoWebScript,
a Tcl based web development tool which could be already familiar to
the a new Rivet user and it wouldn't make sense to confuse him/her.
I can understand this situation, but if they "abandoned" NWS for rivet
they should be prepared to adapt them selfs to something new... I
guess you can tell that I never used NWS and am new to rivet as well ;-)
Seriously though, I think rivet should propose good code even if it
involves deviating from how things were implemented in another
software (where some ideas were taken from). The crucial thing is to
document it well!
Having many procs that make the same job in a different way would
be a possible solution (indroducing switches like "-opt1 -opt2"
received
little appreciation)
Ughh! No please. I'd rather prefer one proc that does what it is
supposed to do correctly.
Cristian's:
for {set i 0} {$i<10} {incr i} { if {[info exists lista]} { set lista
[lappend lista [list elemento $i]] } else { set lista [list
elemento $i] }}
the first element is treated as a 2 elements list whereas the
others are
nested lists appended as sibling elements
The difference between this implementation and the one on rivet is
that [var all] returns already a list , so to compare outputs with
these versions, you should do a foreach {k v} {{elemento 0} {elemento
1} ...} <- the result of [var all], which would produce
{elemento 0} {elemento 1} {elemento 2} ...
Rivet's:
for {set i 0} {$i<10} {incr i} { if {[info exists lista]} { set lista
[list $lista [list elemento $i]] } else { set lista [list elemento
$i] }}
the output in 'lista' is a series of deeply nested elements...
this outputs:
{{{{{{{{{elemento 0} {elemento 1}} {elemento 2}} {elemento 3}}
{elemento 4}} {elemento 5}} {elemento 6}} {elemento 7}} {elemento 8}}
{elemento 9}
I would like to see the code to parse this... I mean, who would want
something like this to be returned!! (I bet someone will speak up now
and say how fun it was to write the function that returned the first
element :-) )
When reading the docs it states that an array is set with the form
variables passed to the page. It is sufficiently criptic to allow for
wild interpretations as how the multivalues would be returned. But as
wild as my imagination would go I couldn't imagine that this kind of
nested list would be returned. that is why the subject of this mail
mentions a possible bug, it was the first thing that came to my mind
when I looked at the code.
You might say that that is my (and possibly your) opinion... but it is
simply impractical to do anything with a result like that. So why have
this kind of code in rivet?
> Or will the load_response proc be deleted from the sources?
>
> Cristian
I think the answer to the last question is negative, this would break
the code and
it wouldn't be a sensible approach to the problem.
Ooops! That last sentence was part of a rant I thought I had
completely deleted and is completely out of context. The rant went on
the fact that the only place where load_response is used in the rivet
sources is in the Diodisplay package and that nothing would be broken
by the change as the code never contemplates the possibility of multi
valued variables. In fact it assumes single values are passed in
several places. Furthermore the fact that nobody except you mentioned
the necessity for multivalued variables (since 2004?) would indicate
that not many people use this proc with multivalued variables so the
risk of breaking things would be small.... etc. Of course all these
inferences are done by reading the code, no real test done yet.
But then again, we could just write a new proc load_form_vars or
something like that and document in a clear manner the output of
load_response if used with multiple values per variable.
So what do you, or the others, think?
Cheers,
Cristian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
