Either/or is fine, a pull request can be slightly simpler if you're working of the current master.
-c On Sat, May 15, 2010 at 1:01 PM, Jarmo <[email protected]> wrote: > Hi. > > I'm trying to make a pull request soon or submit a patch, whichever is > more preferable. Unfortunately i'm kinda busy with school at the > moment so it won't happen right away. > > I think that #th method would be great, but just for searching > elements. For exclusion, you can use regular Array methods like #shift > or #delete_at. > > Jarmo > > On Sat, May 15, 2010 at 9:27 PM, Alan Baird <[email protected]> wrote: > > Jarmo - > > > > I'm looking forward to looking at your code, but while I'm thinking > > about it, you said: > > > >> Also, as a sidenote, there has to be something changed with tables > >> API, because other methods won't work with nested tables correctly and > >> the question is of course, how would > >> be the correct behaviour :) > > > > This was a recent fix in 1.6.5 to make the table itterator always use, > > in your parlance, max_depth = 1. This was added because the itterator > > was using the normal row_count method, which returns the count of all > > <tr>'s regardless of whether they were an immediate child of the table > > or not. Thus, if you are itterating on a table with nested tables, > > you would have to rescue (at least) the itteration to keep your script > > from crashing. > > > > I submit that this should be the default behavior. I think that > > rarely what you want is to really get "all" of the <tr>'s in a nested > > table and if that is what you want, it's probably not the most common > > use case. > > > > Also, I think that it would be really nice to have a .th method for > > tables as well, or a way to exclude them from itteration. Most of the > > time, when I am processing a table, I really want to just look at the > > "data" rows, or sometimes just the header. You can easily accomplish > > this if your devs have put sensible class names for the table rows, > > but if they are using the <th> tags anyway, being able to use them > > will give a certain amount of robustness against changes to the class > > names. > > > > Let me know what you think. > > > > Alan > > _______________________________________________ > > Wtr-development mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
