Welcome to the third installment of This Week in GWT, and the first of this new year. As you recall from last week there was a Request for Review for building a set of "Data Aware Widgets". We pick up this weeks review from there, where the discussion strayed quite a bit from the original message to discuss problems with the existing HTMLTable.
HTMLTable Woes
In the midst of the discussion about Data Aware Widgets Miroslav Pokorny asked the question, "why is there no api to set headers eventually creating a TH with text or widget for any of the Table based widgets". A lot of people thought that was a good question. Some initial work by spaceLenny [his notes] showed that it wasn't trivial to add this to the existing HTMLTable widget. Sandy McArthur tried creating a completely newTable widget with the header/footer functionality, and in the process found some browser incompatibilities [post]. David Evans responded with an alternate approach of manipulating the DOM, which seems to have solved some of the problems [post]. Discussion continued, trying to find solutions to the problems.
[start here]
Flawed Event Model
One interesting tidbit that came up in the table discussion was when Emily Crutcher pointed out flaws in the existing GWT event model. The problem stems from the fact that most of the event listeners receive a Widget or a String as a parameter. This becomes an issue if you later decide that you also want to pass some additional piece of information about the event. They have started to introduce a new "Handler" type of event handler that receives an event object instead of a Widget or String. An example of this is the FormHandler class that has a method onSubmit(FormSubmitEvent). The fact that the event receives an event object instead of the FormPanel widget means that the event object itself can be altered later, adding new information to the event, without breaking backwards incompatibility.
[post]
Request for Review: ConcurrentModificationException
Henry Crutcher posed the following question, "Is the extra run-time checking offered by Sun's fail-fast iterators worth the extra overhead in a browser context? If this were added to web mode, collections would throw ConcurrentModificationException when iterated using an iterator after a modification occurs". It is a question between compliance with the Java standard vs. additional overhead. Most everyone agreed that a fast-fail was a good thing to have, but most everyone agreed that they don't want the additional overhead. The solution that everyone seems to agree on is that we need a way to have these checks in place for testing, then compile them out in the production system.
[thread]
Reflection vs. Generators
Discussion continued on this front with some rather strong opinions on both sides. Joel Webber is concerned about introducing code that he feels could cause difficult to debug runtime errors. Scott Blum felt that the impact on size of the compiled JavaScript would be enormous, but would be willing to hear suggestions on overcoming it. On the opposite side Jon Wells didn't feel that reflection was too "dangerous" to be made available. Neither side was willing to budge. One point that did come out of the discussion was that GWT already supports generators, which is sort of like compile-time reflection. Scott Blum pointed out a few threads on generators from the developers list [thread1][thread2]. <blatant-plug>It may also be worth noting that the forthcoming book GWT in Action includes a chapter on using generators.</blatant-plug>
[full thread]
That's it for this week. Feedback is always appreciated, even if it is just to let me know that you found this useful.
