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.
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.
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.
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.
Reflection vs. Generators
That's it for this week. Feedback is always appreciated, even if it is just to let me know that you found this useful.