DataGrid with several tbody elements possible

[Michael Vogt]

Hello.

We are using the DataGrid for a new widget, and so far all works pretty good. The only missing feature was to add a ScrollHandler to it, so we could add an infinite scrolling feature, which works pretty good.

Now I would like to add some structuring to the data by adding more than one tbody element. The DataGrid prevents this, and I did not find a good way to overwrite this. Also deferred binding replace of some classes failed.

Does someone have a tip for me to get this done?

Issue 5423 (CellTable is not easy to extend) is closed saying:

The next version of GWT (2.5) has a refactored CellTable that internally uses builders that you can inherit, override (not all methods are private), and use instead of the default behavior.

I just don't see how to do it, as all the implementations are created with new instead of GWT.create(), so they can't be replaced by deferred binding, and I don't see a way to register my new builders.

Thanks,

Michael

[Thomas Broyer]

http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/cellview/client/AbstractCellTable.html#setTableBuilder(com.google.gwt.user.cellview.client.CellTableBuilder)

I doubt you'll be able to use several <tbody>s though (AbstractCellTable makes some assumptions about there being a single one IIRC)

[Jens]

You can use DataGrid.setTableBuilder/setHeaderBuilder/setFooterBuilder and provide a custom CellTableBuilder if you want to modify the table's structure. A custom CellTableBuilder can be extended from AbstractCellTableBuilder or DefaultCellTableBuilder.

-- J.

[Michael Vogt]

Thank you both for your quick answers.

Yes I am using the TableBuilder. What's basically needed is a way to overwrite the builders that are used after that, maybe the HtmlBuilderFactory would be a good place, as the current implementation of the call startBody() throws an exception when I try to create another tbody element.

Unfortunately I failed to replace the HTMLBuilderFactory with deferred binding. My own class just was not used.

I am sure there are reasons to allow only one tbody right now. I assume this has to do with the selection handling and the keyboard navigation. I expect I can handle these as I can provide my own implementations for these.

So, maybe my question should have been, "How to provide my own HtmlBuilderFactory".

Greetings,

Michael

[Thomas Broyer]

That wouldn't help. HtmlBuilderFactory is only a type-safe way of building a SafeHtml.

Have a look at AbstractCellTable and how it depends on having a single tbody. If you really need/want several tbodies, you'll have to fork the whole thing; so you could then fork CellTableBuilder to allow it to create several sections (I wonder what kind of "element builder" it could return from finish() though). If I were you, I'd first ask myself whether I really need those multiple tbodies…

[Michael Vogt]

So, maybe my question should have been, "How to provide my own HtmlBuilderFactory".

That wouldn't help. HtmlBuilderFactory is only a type-safe way of building a SafeHtml.

Have a look at AbstractCellTable and how it depends on having a single tbody. If you really need/want several tbodies, you'll have to fork the whole thing; so you could then fork CellTableBuilder to allow it to create several sections (I wonder what kind of "element builder" it could return from finish() though). If I were you, I'd first ask myself whether I really need those multiple tbodies…

Thank you for your answer Thomas.

Yes, I really need it, when there is a way to get there in an acceptable timespan. I'll look into the AbstractCellTable as you suggested and decide then.

Cheers,

Michael