Bret Pettichord wrote: > > inetdavid (6/8/2006 9:38:31 PM): Just found a problem with > row_count with embedded tables. row_count counts *all* the rows, > even rows in sub-tables, while show_tables shows the correct count > because it uses a different method. I've first added a test to > show the problem (using table_test on table(:index, 3) of > table1.html) and I think I have the proper fix to just show/add > rows from within the current table. This is the right way to do > rows, but how do you want to make the change given that some folks > may have coded using the incorrect value? > > > This is http://jira.openqa.org/browse/WTR-26 > > My view is that we should do the right thing. This has been a common > complaint and i don't think there is really much value in trying to > retain the old, incorrect behavior. Is anyone depending on it? > > Comments? I agree, but wanted to check with you before fixing the problem and possibly breaking some existing script. However, I think it's more likely that Watir users have just learned to not trust row_count rather than depend on it's results where it may be in-accurate.
To demonstrate the problem you can load one of the unittest html files that contains a nested table (unittests\html\table1.html). On that page table 4 is a sub-table of table 3, located in row 2, cell 1 of table 3. Table 3 has two rows and table 4 has 1 row, which is properly shown in a show_tables: irb(main):004:0> ie.show_tables Found 6 tables 1 id= rows=2 columns=2 2 id=t1 rows=5 columns=1 3 id=t2 rows=2 columns=2 <== 4 id= rows=1 columns=2 <== 5 id=body_test rows=5 columns=1 6 id=pic_table rows=1 columns=4 => nil The row_count for table 3 is not accurate though as it includes one row which is really inside table 4. (The row_count for all other tables is correct.) irb(main):005:0> ie.table(:index, 3).row_count => 3 irb(main):006:0> ie.table(:index, 4).row_count => 1 The to_a method has the same problem. You see the embedded table's values in multiple places, and the last array element is really an array from the embedded table. irb(main):007:0> ie.table(:index, 3).to_a => [["cell 1", "cell2"], ["nest1nest2", "nest1", "nest2", "Normal"], ["nest1", " nest2"]] irb(main):008:0> ie.table(:index, 4).to_a => [["nest1", "nest2"]] irb(main):009:0> The reason for the different counts became apparent when I looked at the DOM calls available that are being used. Using nested tables as an example, there is a "rows" call for tables, and that "rows" element has only two calls available: irb(main):017:0> ie.table(:index, 3).document.rows.ole_get_methods.sort => [_newEnum, length] This is the method used in show_tables, which is always accurate and gives you a count of how many rows are in the table. However, the method used within Watir to get all rows is getElementsByTagName, which returns *all* objects with a given tag below the current element. If you examine the DHTML Reference document for the TABLE Element (http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/table.asp) you can see that the "rows" method returns a collection of "tr" elements for the current table: irb(main):034:0> ie.table(:index, 3).document.rows.each do |row| irb(main):035:1* print "\nNew row:" irb(main):036:1> puts row.outerHTML irb(main):037:1> end New row: <TR><TD>cell 1 <TD>cell2 </TD> New row: <TR><TD> <TABLE> <TBODY> <TR> <TD>nest1 <TD>nest2</TR></TBODY></TABLE> <TD>Normal </TD> => nil This works as it should. We can now re-code the Table#to_a method to properly iterate only over the proper rows. However, the getElementsByTagName method is called from many different places within Watir, and one of the places is Container#locate_tagged_element, which uses getElementsByTagName for many different tag types. The problem with this is that while the same method is used to get ALL tags of a given type, each DOM element has it's own *specfic* method to return the collection of specific child nodes (like "rows" for table rows, "cells" for table cells, etc). I think we'll have to look at each of those calls to getElementsByTagName to see if the call is appropriate, and re-code each if not. (The "show" methods can still use the getElementsByTagName because they can then show all sub-elements of the desired type, like the ie.show_tables method.) I think the first step will be to create unit tests to show each of the problems and then put in the code to fix each of the count problems till all the unit tests pass. Bret, do you want me to start on this? David _______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
