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
-~----------~----~----~----~------~----~------~--~---

Reply via email to