On Sat, Mar 23, 2013 at 10:09 AM, Stephen Haberman <[email protected] > wrote:
> > > It should ideally work well with different native/non-native widget > > sources. > > Just curious, but what do you mean by this? > > Widgets written as current generation of GWT widgets in java vs native js widgets (e.g. closure) > > I have more radical ideas like introducing a pseudo-widget layer, so > > that developers can program around interface definitions (like Label, > > TextInput, Button, Link, Select) that are deferred-bound at > > application level. > > Seems reasonable, although I think this is probably only a fancy way of > theming (which is fine if that's what you intend), because as soon as widgets want to offer different/fancier features, they'll have to > embrace & extend the generic interface, and you'll be locked into that > implementation. > > Theming with css is pretty limited. Appearance pattern solves many problems but still lock you to the initial assumptions (e.g. custom GWT widget vs a simple DOM element). I hit this problem in new Listbox style that is currently in use by Google. Changing the previous internal widget already written around appearance pattern was not feasible to adapt to new style due the behavior put in to the widget itself that is assumed to be common. If you want use some fancy feature that is not available in common interface, then yes you might be locked. But if you are developing some forms then you usually don't need/care fancy stuff. Also hopefully it will require less work to switch when you locked out as it can provide a reference/shared base API that can be re-used across different vendors. Of course there are benefits to testability as well (isn't that why you want to add IsXXX interfaces?). > Just curious/tangentially, do you think today's widgets could be > (partially) modernized by replacing the old "doesn't leak in IE6" event > system? Would there be any significant benefit? Or not really worth it > at this point? > > I guess it depends on what you mean by modernizing. It will definitely help to integration with other widget systems (like closure) and simplify code. However, important part of modernization of current widgets in GWT is the APIs and themes. APIs are not well thought out and sometimes surprising - how can a selection widget (ListBox) not have a getSelectedValue method? Listbox API is crowded but not helping me doing what I need to do 95% of the time. It goes similar with Colin's point of logical events. > > If you have similar or alternative ideas, feel free to experiment, > > share and advocate for it :) > > Okay, will do. :-) > > > On our side, when I have a more concrete proposal, I will definitely > > talk publicly about it to get feedback. I believe that any new major > > addition to GWT should first prove itself in real life before finding > > a home in GWT SDK, whether it is coming from GWT team or not. > > Cool. I generally agree, although if ideas get too far to the "real > life" point internally, I worry it might be too late for external input > to really fundamentally change the approach. > > Or that it will be like projects like RequestFactory/UiBinder, where > there are probably tons of internal design docs/whiteboard sessions > about the awesome things RF/UiBinder do, and why they are built the way > they are, but once the code hits the repo, the outside people are left > going "huh? ...looks cool...I guess..." > > But perhaps that is just the lot in life of a project with significant > work coming from salaried developers. > > - Stephen > > -- > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "Google Web Toolkit Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
