On 10/4/07, Massimo Manghi <[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
