This is the second installment of This Week in GWT, and some of you may have noticed that I have already skipped a week. For those of you that celebrate Christmas, it was last weekend, and for Christmas this year I got the flu. And it was a grand flu at that. I wasn't much in the mood for writing. But enough of my problems, lets get back on track and cover the highlights of these past two weeks.
Request for Review: Vector API
Mark Bakker looking for some feedback posted a note about adding SVG, VML, and canvas support to GWT. He also thought that it would be a good idea to also have a high-level vector API that would emit either SVG, VML, or canvas code depending on the client browser. Emily Crutcher, speaking for Google, said that browser specific APIs are something that are trying to avoid, but a generic vector API is something that they are interested in. Discussion ensued, and nobody disliked the idea. After doing some research Mark Baker posted a Request for Review, describing what the Vector API would look like. The RR did not include canvas support, which means no Safari support. The API probably won't fly without Safari support, but as Kelly Norton pointed out, the Apple Webkit does have SVG support, so sooner or later SVG should end up in Safari.
[thread][Request for Review]
Request for Review: Data aware widgets
Emily Crutcher posted a RR for a data-aware widgets. In the scheme there are two participants, a data-aware widget, and a request broker. The widget would create a request object, and pass it to the request broker for processing. The request broker handles the request, most likely performing some sort of RPC calls to the server, and returns a response to the widget. The widget then uses the response data to populate itself. The goal is to simplify the code required to populate widgets, and to increase start-up times by using asynchronous data population. The initial widget set would include a data tree, data table, data list-box, and suggest pop-up. Discussion on the topic went this way and that. Questions of inheritance vs. composition were raised, as was widget proliferation. Regarding widget proliferation Konstantin Scheglov compared the idea to Delphi, where you had base widgets with a higher-level set of data-aware widgets on top of that. Others agreed, also comparing it to SWT/JFace. So far it looks like there is some interest, but no overwhelming enthusiasm.
[Request for Review]
Reflection
There were a couple of request for reflection support, including one from Zuhayr Khan. In his case he has found a way to get around the limitation by using a little JSNI along with a init() block that calls the needed methods so that they aren't optimized out of the code by the compiler. He suggested an extension to the module config file that would inform the compiler of interfaces that should not be optimized out of the compiled code. So far no responses, but I think that is due to it being a long weekend for most people. The other request for the same came from jdoubleu, but he wasn't aware of the compiler optimizations, so Scott Blum enlightened him. In that thread mP suggested using annotations to mark methods that should not be pruned.
[ZK thread][jdoubleu thread]
That's it for this week. Have a great New Year!
No comments:
Post a Comment