Even worse, rowspans effect the coordinates of cells that they overlap, but colspans do not. :-/
On Tue, Oct 21, 2008 at 18:04, Charles Fry <[EMAIL PROTECTED]> wrote: > As a new GWT user (thanks a ton for the awesome toolkit) I have a few > issues with table columns: > > 1) To my surprise, FlexTable row and column spans effect the offsets > of later cells in the row/column of the span. In other words the row > and column numbers passed as arguments into all of the methods are > relative and not absolute indices (being offset by any spans before > them). In addition to being undocumented (at least in the Javadocs), I > found this completely counter-intuitive. I recognize that this maps to > how HTML tables are implemented with respect to <tr> and <td> tags, > but I thought that the whole point of having an API that allowed > row/column references was to provide a higher-level abstraction. As it > is, it is completely impossible (as far as I can tell) to manipulate > FlexTable cells using absolute coordinates. Any operation pre-supposes > full knowledge of any spans that may be in effect (or come into > effect). I guess this makes it easier from your perspective to > dynamically shift cells when a span is in effect, but given the > indices used for all operations, I would have found it much more > intuitive for spans to simply hide cell content that had been set but > collided with a span. Am I missing something here? Is there a way to > achieve absolute referencing? At the very least, the current behavior > should be clearly documented, but I still find it very suspect. I > assume that currently you can use setText/Widget to put content in a > cell, and then create a span, and then later go to update the original > cell using the same indices, only to find that those indices now apply > to a different cell. Weird. > > 2) I was sad to discover that HTMLTables have a removeCell call and a > removeRow call, but no removeColumn call. This feels inconsistent. > Isn't the abstraction's purpose to let you think about things at a > higher level than the base <tr><td> tags? I would find a removeColumn > call to be justified, even if it was documented as being expensive to > execute on large tables (if that is the reason it is not included, for > example). > > 3) In a similar vein, it is odd that HTMLTable allows you to > getRowCount and getCellCount, but not getColumnCount. That would be > awfully convenient to have as well. > > I'd love to hear what any of the developers have to say about all > this. At the very least it should all be documented better, but I > would like to hope that table columns might ultimately become more > first class citizens, with their offsets being fixed. :-) > > Charles > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---