Hi there,
In my app I need to create a table with several sections, by using several tbody elements. For those how are wondering, yes, that's supported by the W3C spec: a table can have multiple tbody elements (see this question at StackOverflow for details).
I really need several tbody elements because the data structure and styling needed for each section cannot be achieved by just adding more table rows, or "header rows".
That being said, I started my research trying to find a way to do that with DataGrid/CellTable on GWT.
And then I found this thread:
https://groups.google.com/forum/#!topic/google-web-toolkit/6VxudGY11OA
... which states that:
and
Well, in my opinion the framework is not supposed to judge if you need something or not, if what you want is supported by the specs. Anyway, the "you'll have to fork the whole thing" got me puzzled... How hard it would be to fork it?
First step is to create a custom CellTableBuilder. And by that I mean a class that implements CellTableBuilder directly, since we cannot use the DefaultCellTableBuilder or even the AbstractCellTableBuilder, because the "HtmlTableSectionBuilder tbody" object I need to access is private on AbstractCellTableBuilder. So I created a CustomCellTableBuilder with most code copied from AbstractCellTableBuilder and DefaultCellTableBuilder.
Ugly, but now I have access to the HtmlTableSectionBuilder object. Next step is to change it to allow multiple tbody elements.
And now the things started to be a real mess. The HtmlElementBuilderBase, which is the parent class of HtmlTableSectionBuilder, doesn't accept multiple top level tags. You are forced to start a tag and put stuff into it. And it gets worse: if you try to extend the HtmlElementBuilderBase to create your own builder, you just can't... because the constructor requires a HtmlBuilderImpl oject, which is only visible at package level (com.google.gwt.dom.builder.shared) !
And then I figured out what the "you'll have to fork the whole thing" means: I'd have to really fork the whole thing.
It's not the first time I stumble on package scoped classes or private fields/methods that forbids you to create a custom behaviour (even if that behaviour is supported by the specs). So I came with some questions:
Why GWT is designed that way, so hard to extend? Is that a reflection of a desperate need for contributors to the project, by having to "fork the whole thing"? Or is it to force the developers to use paid frameworks built on top of GWT?
Why package-scoped classes?
Why private fields on classes that are supposed to be extended?
In pure Java, such bad design for extension points can be treated with reflection. Not beautiful, not best performance, but it works. In GWT that's not an option, so we are left to "fork the whole thing".
I really hope that future versions of GWT have a better approach to extension points. The framework shouldn't forbid the developer from making his own choices.
-- In my app I need to create a table with several sections, by using several tbody elements. For those how are wondering, yes, that's supported by the W3C spec: a table can have multiple tbody elements (see this question at StackOverflow for details).
I really need several tbody elements because the data structure and styling needed for each section cannot be achieved by just adding more table rows, or "header rows".
That being said, I started my research trying to find a way to do that with DataGrid/CellTable on GWT.
And then I found this thread:
https://groups.google.com/forum/#!topic/google-web-toolkit/6VxudGY11OA
... which states that:
[...] If you really need/want several tbodies, you'll have to fork the whole thing
and
[...] If I were you, I'd first ask myself whether I really need those multiple tbodies…
Well, in my opinion the framework is not supposed to judge if you need something or not, if what you want is supported by the specs. Anyway, the "you'll have to fork the whole thing" got me puzzled... How hard it would be to fork it?
First step is to create a custom CellTableBuilder. And by that I mean a class that implements CellTableBuilder directly, since we cannot use the DefaultCellTableBuilder or even the AbstractCellTableBuilder, because the "HtmlTableSectionBuilder tbody" object I need to access is private on AbstractCellTableBuilder. So I created a CustomCellTableBuilder with most code copied from AbstractCellTableBuilder and DefaultCellTableBuilder.
Ugly, but now I have access to the HtmlTableSectionBuilder object. Next step is to change it to allow multiple tbody elements.
And now the things started to be a real mess. The HtmlElementBuilderBase, which is the parent class of HtmlTableSectionBuilder, doesn't accept multiple top level tags. You are forced to start a tag and put stuff into it. And it gets worse: if you try to extend the HtmlElementBuilderBase to create your own builder, you just can't... because the constructor requires a HtmlBuilderImpl oject, which is only visible at package level (com.google.gwt.dom.builder.shared) !
And then I figured out what the "you'll have to fork the whole thing" means: I'd have to really fork the whole thing.
It's not the first time I stumble on package scoped classes or private fields/methods that forbids you to create a custom behaviour (even if that behaviour is supported by the specs). So I came with some questions:
Why GWT is designed that way, so hard to extend? Is that a reflection of a desperate need for contributors to the project, by having to "fork the whole thing"? Or is it to force the developers to use paid frameworks built on top of GWT?
Why package-scoped classes?
Why private fields on classes that are supposed to be extended?
In pure Java, such bad design for extension points can be treated with reflection. Not beautiful, not best performance, but it works. In GWT that's not an option, so we are left to "fork the whole thing".
I really hope that future versions of GWT have a better approach to extension points. The framework shouldn't forbid the developer from making his own choices.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment