Hi!

I'm generating some tables for data input and I'd like to perform one
calculation automatically, so I'd connect all inputs from one column to an
onchange event (using MochiKit.Signal, of course).

If I have something like 1000 rows on this table, would having 1000 "connect"s
be too much?  Is there a better way to make this automatic?  (I'd like to
avoid having to press a button to perform the calculation, but if there's no
way this is what I'll implement...)

This will be running mainly on Firefox (Linux and Windows) and Internet
Explorer (Windows).  Machines are reasonably fine and running Windows XP
(there's one with an updated version of IE running Windows 98, but only
because of other software, I believe it would run XP just fine.).

Thanks for any comments on that.

Thanks for your answer.

Since I'm also generating the table dinamically, I'm doing the process in two
steps:

    - creating the tables & using swapDOM to put them on screen (loops through
      the data)

    - looping again and connecting signals to the calculation function (I
      can't use the same loop because there's no element to connect to...)

This was my first approach, just to see if it would work for the client -- and
it does -- but I'm willing to make it robust and "correct".

I'll be doing the tests next Wednesday (I might be asking for the client to
test it before, but you know that his description is never like our "feeling"
of it...) and I'll post here the results.

For too many fields where filling them is a slow process it would be great to
be able to detect what has changed and do the operation just on it instead of
recalculating everything all the time (imagine how many useless calculations
would be done until the user fills 100 -- very very trivial to have that here,
common case would be something like 300... -- cells with values like "0,53",
"0,542", etc.).  

I would really prefer having something that is dinamically connected to each
cell that needs to be recalculated.

I finally got back to this project and you're correct.  I get a window asking
if I want to continue or to interrupt the script that is running.  I'll think
more about this...  Maybe if I mount the table piece by piece, putting blocks
of 100 rows each time this gets more manageable.

The main code for my test is:

  for (var index; index < 400; index++) {
    var sample = index;
    log ('Sample:', sample);
    var elements = [sample,
      INPUT({'name':sample+':sample',
             'id':sample+':sample'}, null),
      LABEL({'name':sample+':result',
             'id':sample+':result'}),
      [INPUT({'name':sample+':ignore_sample',
              'id':sample+':ignore_sample',
              'value': true,
              'type': 'checkbox'}, null),
       LABEL(null, 'Ignore Reading'),],
       ];
    extend(lines, new Array(elements));
    }

and later, in another function (after swapDOM...):

      for (var index; index < 400; index++) {
          var sample = index+':sample';
          connect(sample, 'onchange', calculate_results);
      }

Any hints on how to make it better would be appreciated.

On Jul 25, 2006, at 4:20 PM, Jorge Godoy wrote:

Also, index isn't initialized to 0.. so the first run through is  
going to be undefined... that can't be correct as written here.

I've just made a few simplifications from my real case (where my for loop
iterates of a JSON result containing data that will be turned into table rows
instead of generating a loop with "known" indexes), but kept the structure of
everything else.

On Jul 25, 2006, at 5:30 PM, Jorge Godoy wrote:

Could you take a look at it?  Is my code wrong?  Should I adopt a different
approach to the problem? :-)

I'm really willing to go on with this part of the code (even though I'm
working on different parts simultaneously, this is pending on my side...).

If you used native browser events to connect to a lot of elements,  
your page would probably slow to a crawl as well. I don't think your  
code or Signal are introducing any other problems on top of this one.

A solution to your problem might be to connect() at a higher level  
for an event, say on document or window. From there, you can see  
where it came from (http://mochikit.com/doc/html/MochiKit/
Signal.html#fn-target). Something like this *should* work in your  
situation, but you'll need to write and test the code to be sure.