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.
I was enjoying these posts especially since they were chronicling my epic battle for reflection -- heh. Where'd they go?
> Where'd they go?
Glad to hear there is interest, I wasn't entirely sure that they were being read.
The reflection battle sizzled, then died. The new battle is for adding a mechanism for specifying styles that works across browsers. This one is likely to die as well because none of the GWT commiters has been convinced that it needs to be added.
I'll have to see what I can do about starting these up again since with the changes coming in 1.4 there is a lot to write about.
> The new battle is for adding a mechanism
> for specifying styles that works across
> browsers. This one is likely to die as
> well because none of the GWT commiters
> has been convinced that it needs to be
Well, I wouldn't put it quite like that. There will most likely be *some* form of CSS/style-management framework, because there is clearly a need.
The primary objection is that this idea introduces complexity to the core system, but doesn't really solve the key problem: okay, you've got a handle to a style object. Now what? Write a bunch of lines of code that set styles on it? That's too programmatic, and seems brittle if you need to redesign your CSS.
We would prefer to see (and are in the early stages of working on) a more web-designer-oriented, less user-code-intrusive mechanism for handling CSS.
Post a Comment