I can see where that would be confusing, and the JavaDoc should be updated. Balancing performance and usability can be very tricky in a web browser. Whereas in a Java world we can use hash maps and some O(n^2) logic (I don't really know if the algorithm is this bad) to keep track of row and cell indexes without worrying about performance for tables that are less than 100 rows, there exists a very real cost on a browser in both code size and performance. For example, removing a column would require the removal of multiple cells at different indexes and the updating of rowspans and colspans, where the removal of each cell takes real time (as opposed to the millisecond it takes in a pure java app).
Its unlikely that we'll change more than the JavaDoc in this case because of legacy support and the cost of the code, but even if there is an efficient algorithm, it raises other fundamental questions. GWT is a cross-browser development language that abstracts a lot of the browser-specific quirks people are used to dealing with, but it doesn't necessarily hide the fact that developers are programming a web page. I'd like to get some input on the "ideal Java API" versus "coorelates to JavaScript/HTML where appropriate" approach, but I'd argue that this is more of a balancing act without a perfect center. Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Oct 27, 2008 at 5:45 PM, Charles Fry <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
