[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Ahhh the famous "lock-in" reason. Yep, understandable... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > > You lost me here. I think I misunderstand something. > If the compiler get ride of the overridden code, "causing code bloat" > isn't a reason to not allow subclassing like you mention above, not? > Ah! I see the misunderstanding, nope, that was the justification for why it could be done efficiently, not why it should be done. The justification for why it should be done is different: If we allow subclasses, then we have to make pretty strong guarantees about how the default calendar view and month selector are implemented. That means that if GWT 2.0, if we figure out an awesome new way to write the default calendar view that blows the socks off of the old implementation, we wouldn't be able to switch to it. > > On Sep 25, 5:26 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > do not cause code bloat. > > > Isn't the GWT compiler smart enough to overcome this? > > > I hope so. I have a quite a lot of gwt classes and many subclasses for > > > simple OO reasons :( > > > > Yep, that is actually my point - that the compiler is smart enough > > to aggressively get rid of unused code, so the defaults will be > completely > > dropped in favor of your custom code. > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > > > do not cause code bloat. > Isn't the GWT compiler smart enough to overcome this? > I hope so. I have a quite a lot of gwt classes and many subclasses for > simple OO reasons :( > > Yep, that is actually my point - that the compiler is smart enough to aggressively get rid of unused code, so the defaults will be completely dropped in favor of your custom code. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> Yep, that is actually my point - that the compiler is smart enough > to aggressively get rid of unused code, so the defaults will be completely > dropped in favor of your custom code. You lost me here. I think I misunderstand something. If the compiler get ride of the overridden code, "causing code bloat" isn't a reason to not allow subclassing like you mention above, not? On Sep 25, 5:26 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > do not cause code bloat. > > Isn't the GWT compiler smart enough to overcome this? > > I hope so. I have a quite a lot of gwt classes and many subclasses for > > simple OO reasons :( > > Yep, that is actually my point - that the compiler is smart enough > to aggressively get rid of unused code, so the defaults will be completely > dropped in favor of your custom code. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Thanks for your answers Emily, > Did you look at the date picker in gen2? The Css class there is public. Nope. Where can I find this? (the source of incubator or core ?...) I looked around in GWT and incubator site... but... I think I am looking with my eyes closed :( > Actually, and I know you are going to hate this answer, Don't worry ;) > do not cause code bloat. Isn't the GWT compiler smart enough to overcome this? I hope so. I have a quite a lot of gwt classes and many subclasses for simple OO reasons :( > We may also, if there is enough demand for it, introduce > AbstractMonthSelector and AbstractCalendarView which are specifically +1 +1, but probably have them done soon :) > The month and calendar view APIs are not designed for the date picker Waaaa you guys are strict > picker, it will work with the new event system and css resources, which will > make it more useable for you in the long run. Will this come available in the incubator? Or where can I read some more about these gen2 components (idea, pan, roadmap, etc..). Isn't the current DatePicker not already using the new event system? What is this new css resouces ? Do you mean the CssResource in the incubator? -- Ed On Sep 25, 3:50 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > I think in general the DatePicker should be made more usable. Here are > > a few things I don't understand: > > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > > want to use it in my own selector just like happens in the > > SimpleMonthSelector. > > Did you look at the date picker in gen2? The Css class there is public. > > > > > - The SimpleMonthSelector isn't usable. The method should be splitup > > in smaller protected methods such that this functionality can be used > > and the subclass can compose his own functionality. I am case I need > > to only change the listeners but those are set in the setup, such that > > I need to override the whole setup, but I need the other functionality > > in setup for the buttons and stuff and the styles, especially as this > > latter one is needed as I can't access the Style class (previous > > point). > > Actually, and I know you are going to hate this answer, > SimpleMonthSelector (now called DefaultMonthSelector) is not designed for > extension at all, neither is SimpleCalendarView (now called > DefaultCalendarView). > > The current pattern is to have you take the implementations, copy and modify > them to your needs. Once you do so, and use your modified month and view > selectors, the default ones will not be included in your compilation and so > do not cause code bloat. This way, we don't have to worry about those of you > extending the default extenders and can instead worry about the vast number > of people using the date picker widget. Before submitting the widget, we > will run tests to make sure that the defaults can be cleanly copied to > another package without causing any compilation errors. > > We may also, if there is enough demand for it, introduce > AbstractMonthSelector and AbstractCalendarView which are specifically > designed for extension (may even try to convince Isaac to write them :-). > > > - Why do I need to subclass DatePicker to use my own MonthSelector?... > > Why is this DatePicker constructor protected and not public ? > > The month and calendar view APIs are not designed for the date picker > consumer, instead they are meant for people extending DatePicker. > Therefore, if you look at the public API, you will see that there is no > public use of either class in date picker. In specific, rather then users > trying to figure out which month selectors go with which calendar views, > they should have a set number of pre-canned choices. > > > > > I am thinking about copying the whole DatePicker to my own space as I > > can't use it like this :(... but I do want to use it... > > I think in your case, that is a terrific idea, as that way you will get the > fine-grain control you want and can refactor the classes at will. You might > want to hold off a few days though, wait until the gen2 date > picker stabilizes. As it, while much less stable then the current date > picker, it will work with the new event system and css resources, which will > make it more useable for you in the long run. > > Cheers, > > Emily > > > > > > > -- Ed > > > On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > Are you extending MonthSelector or DatePickerComponent? MonthSelector is > > > public, so if you are extending that, could you create an issue, as that > > > should darn well work, though you will have to create a new subclass of > > > DatePicker to use your new month selector as well. > > > > On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote: > > > > > Why is the class DatePickerComponent of the DatePicker protected ? I > > > > want to add my own MonthSelector, but when I do this, it throws an > > > > access exception becau
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Check out the thread: RR: Introducing the gen2 incubator packageFeel free to respond to that thread if you have any questions in order to maintain thread coherence. On Thu, Sep 25, 2008 at 11:21 AM, Ed <[EMAIL PROTECTED]> wrote: > > Ooppsss, found the gen2 components :(.. > But why are the not the same as the "normal" incubator components? > What is the plan and idea behind this ? > > -- Ed > > On Sep 25, 5:14 pm, Ed <[EMAIL PROTECTED]> wrote: > > Thanks for your answers Emily, > > > > > Did you look at the date picker in gen2? The Css class there is public. > > > > Nope. Where can I find this? (the source of incubator or core ?...) > > I looked around in GWT and incubator site... but... I think I am > > looking with my eyes closed :( > > > > > Actually, and I know you are going to hate this answer, > > > > Don't worry ;) > > > > > do not cause code bloat. > > > > Isn't the GWT compiler smart enough to overcome this? > > I hope so. I have a quite a lot of gwt classes and many subclasses for > > simple OO reasons :( > > > > > We may also, if there is enough demand for it, introduce > > > AbstractMonthSelector and AbstractCalendarView which are specifically > > > > +1 +1, but probably have them done soon :) > > > > > The month and calendar view APIs are not designed for the date picker > > > > Waaaa you guys are strict > > > > > picker, it will work with the new event system and css resources, which > will > > > make it more useable for you in the long run. > > > > Will this come available in the incubator? Or where can I read some > > more about these gen2 components (idea, pan, roadmap, etc..). > > Isn't the current DatePicker not already using the new event system? > > What is this new css resouces ? Do you mean the CssResource in the > > incubator? > > > > -- Ed > > > > On Sep 25, 3:50 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > > > I think in general the DatePicker should be made more usable. Here > are > > > > a few things I don't understand: > > > > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > > > > want to use it in my own selector just like happens in the > > > > SimpleMonthSelector. > > > > > Did you look at the date picker in gen2? The Css class there is public. > > > > > > - The SimpleMonthSelector isn't usable. The method should be splitup > > > > in smaller protected methods such that this functionality can be used > > > > and the subclass can compose his own functionality. I am case I need > > > > to only change the listeners but those are set in the setup, such > that > > > > I need to override the whole setup, but I need the other > functionality > > > > in setup for the buttons and stuff and the styles, especially as this > > > > latter one is needed as I can't access the Style class (previous > > > > point). > > > > > Actually, and I know you are going to hate this answer, > > > SimpleMonthSelector (now called DefaultMonthSelector) is not designed > for > > > extension at all, neither is SimpleCalendarView (now called > > > DefaultCalendarView). > > > > > The current pattern is to have you take the implementations, copy and > modify > > > them to your needs. Once you do so, and use your modified month and > view > > > selectors, the default ones will not be included in your compilation > and so > > > do not cause code bloat. This way, we don't have to worry about those > of you > > > extending the default extenders and can instead worry about the vast > number > > > of people using the date picker widget. Before submitting the widget, > we > > > will run tests to make sure that the defaults can be cleanly copied to > > > another package without causing any compilation errors. > > > > > We may also, if there is enough demand for it, introduce > > > AbstractMonthSelector and AbstractCalendarView which are specifically > > > designed for extension (may even try to convince Isaac to write them > :-). > > > > > > - Why do I need to subclass DatePicker to use my own > MonthSelector?... > > > > Why is this DatePicker constructor protected and not public ? > > > > > The month and calendar view APIs are not designed for the date picker > > > consumer, instead they are meant for people extending DatePicker. > > > Therefore, if you look at the public API, you will see that there is no > > > public use of either class in date picker. In specific, rather then > users > > > trying to figure out which month selectors go with which calendar > views, > > > they should have a set number of pre-canned choices. > > > > > > I am thinking about copying the whole DatePicker to my own space as I > > > > can't use it like this :(... but I do want to use it... > > > > > I think in your case, that is a terrific idea, as that way you will get > the > > > fine-grain control you want and can refactor the classes at will. You > might > > > want to hold off a few days though, wait until the gen2 date > > > picker stabilizes. As it, while much less stable then the curre
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Ooppsss, found the gen2 components :(.. But why are the not the same as the "normal" incubator components? What is the plan and idea behind this ? -- Ed On Sep 25, 5:14 pm, Ed <[EMAIL PROTECTED]> wrote: > Thanks for your answers Emily, > > > Did you look at the date picker in gen2? The Css class there is public. > > Nope. Where can I find this? (the source of incubator or core ?...) > I looked around in GWT and incubator site... but... I think I am > looking with my eyes closed :( > > > Actually, and I know you are going to hate this answer, > > Don't worry ;) > > > do not cause code bloat. > > Isn't the GWT compiler smart enough to overcome this? > I hope so. I have a quite a lot of gwt classes and many subclasses for > simple OO reasons :( > > > We may also, if there is enough demand for it, introduce > > AbstractMonthSelector and AbstractCalendarView which are specifically > > +1 +1, but probably have them done soon :) > > > The month and calendar view APIs are not designed for the date picker > > Waaaa you guys are strict > > > picker, it will work with the new event system and css resources, which will > > make it more useable for you in the long run. > > Will this come available in the incubator? Or where can I read some > more about these gen2 components (idea, pan, roadmap, etc..). > Isn't the current DatePicker not already using the new event system? > What is this new css resouces ? Do you mean the CssResource in the > incubator? > > -- Ed > > On Sep 25, 3:50 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > I think in general the DatePicker should be made more usable. Here are > > > a few things I don't understand: > > > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > > > want to use it in my own selector just like happens in the > > > SimpleMonthSelector. > > > Did you look at the date picker in gen2? The Css class there is public. > > > > - The SimpleMonthSelector isn't usable. The method should be splitup > > > in smaller protected methods such that this functionality can be used > > > and the subclass can compose his own functionality. I am case I need > > > to only change the listeners but those are set in the setup, such that > > > I need to override the whole setup, but I need the other functionality > > > in setup for the buttons and stuff and the styles, especially as this > > > latter one is needed as I can't access the Style class (previous > > > point). > > > Actually, and I know you are going to hate this answer, > > SimpleMonthSelector (now called DefaultMonthSelector) is not designed for > > extension at all, neither is SimpleCalendarView (now called > > DefaultCalendarView). > > > The current pattern is to have you take the implementations, copy and modify > > them to your needs. Once you do so, and use your modified month and view > > selectors, the default ones will not be included in your compilation and so > > do not cause code bloat. This way, we don't have to worry about those of you > > extending the default extenders and can instead worry about the vast number > > of people using the date picker widget. Before submitting the widget, we > > will run tests to make sure that the defaults can be cleanly copied to > > another package without causing any compilation errors. > > > We may also, if there is enough demand for it, introduce > > AbstractMonthSelector and AbstractCalendarView which are specifically > > designed for extension (may even try to convince Isaac to write them :-). > > > > - Why do I need to subclass DatePicker to use my own MonthSelector?... > > > Why is this DatePicker constructor protected and not public ? > > > The month and calendar view APIs are not designed for the date picker > > consumer, instead they are meant for people extending DatePicker. > > Therefore, if you look at the public API, you will see that there is no > > public use of either class in date picker. In specific, rather then users > > trying to figure out which month selectors go with which calendar views, > > they should have a set number of pre-canned choices. > > > > I am thinking about copying the whole DatePicker to my own space as I > > > can't use it like this :(... but I do want to use it... > > > I think in your case, that is a terrific idea, as that way you will get the > > fine-grain control you want and can refactor the classes at will. You might > > want to hold off a few days though, wait until the gen2 date > > picker stabilizes. As it, while much less stable then the current date > > picker, it will work with the new event system and css resources, which will > > make it more useable for you in the long run. > > > Cheers, > > > Emily > > > > -- Ed > > > > On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > Are you extending MonthSelector or DatePickerComponent? MonthSelector > > > > is > > > > public, so if you are extending that, could you create an issue, as that > > > > should darn w
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> And it doesn't give me any problems.
extending DatePicker isn't the problem. Extending the MonthSelector is
the problem.
Which extends the DatePickercomponent which is package protect. When I
change this to public, it works fine, so it must be that.
On Sep 25, 3:39 pm, "Isaac Truett" <[EMAIL PROTECTED]> wrote:
> Ed,
>
> Extending MonthSelector definitely is possible. I have this:
>
> public class MyDatePicker extends DatePIcker {
> public MyDatePIcker() {
> super(new MyMonthSelector(), new SimpleCalendarView(), new
> CalendarModel());
> }
>
> static class MyMonthSelector extends MonthSelector {
> ...
> }
>
> }
>
> And it doesn't give me any problems.
>
> Would it be possible for you to post your modified DatePickerDemo to
> show us where that exception is coming from?
>
> Thanks,
> Isaac
>
> On Thu, Sep 25, 2008 at 9:22 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
> >> The same error occurs when I extend the MonthSelector. Please verify
> >> this?
>
> > I will see if I can get it to repro, thanks!
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > I think in general the DatePicker should be made more usable. Here are > a few things I don't understand: > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > want to use it in my own selector just like happens in the > SimpleMonthSelector. Did you look at the date picker in gen2? The Css class there is public. > > - The SimpleMonthSelector isn't usable. The method should be splitup > in smaller protected methods such that this functionality can be used > and the subclass can compose his own functionality. I am case I need > to only change the listeners but those are set in the setup, such that > I need to override the whole setup, but I need the other functionality > in setup for the buttons and stuff and the styles, especially as this > latter one is needed as I can't access the Style class (previous > point). Actually, and I know you are going to hate this answer, SimpleMonthSelector (now called DefaultMonthSelector) is not designed for extension at all, neither is SimpleCalendarView (now called DefaultCalendarView). The current pattern is to have you take the implementations, copy and modify them to your needs. Once you do so, and use your modified month and view selectors, the default ones will not be included in your compilation and so do not cause code bloat. This way, we don't have to worry about those of you extending the default extenders and can instead worry about the vast number of people using the date picker widget. Before submitting the widget, we will run tests to make sure that the defaults can be cleanly copied to another package without causing any compilation errors. We may also, if there is enough demand for it, introduce AbstractMonthSelector and AbstractCalendarView which are specifically designed for extension (may even try to convince Isaac to write them :-). > - Why do I need to subclass DatePicker to use my own MonthSelector?... > Why is this DatePicker constructor protected and not public ? > The month and calendar view APIs are not designed for the date picker consumer, instead they are meant for people extending DatePicker. Therefore, if you look at the public API, you will see that there is no public use of either class in date picker. In specific, rather then users trying to figure out which month selectors go with which calendar views, they should have a set number of pre-canned choices. > > I am thinking about copying the whole DatePicker to my own space as I > can't use it like this :(... but I do want to use it... > I think in your case, that is a terrific idea, as that way you will get the fine-grain control you want and can refactor the classes at will. You might want to hold off a few days though, wait until the gen2 date picker stabilizes. As it, while much less stable then the current date picker, it will work with the new event system and css resources, which will make it more useable for you in the long run. Cheers, Emily > > > -- Ed > > > > > > > On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > Are you extending MonthSelector or DatePickerComponent? MonthSelector is > > public, so if you are extending that, could you create an issue, as that > > should darn well work, though you will have to create a new subclass of > > DatePicker to use your new month selector as well. > > > > On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote: > > > > > Why is the class DatePickerComponent of the DatePicker protected ? I > > > want to add my own MonthSelector, but when I do this, it throws an > > > access exception because this class it protected :( > > > > -- > > "There are only 10 types of people in the world: Those who understand > > binary, and those who don't" > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Ed,
Extending MonthSelector definitely is possible. I have this:
public class MyDatePicker extends DatePIcker {
public MyDatePIcker() {
super(new MyMonthSelector(), new SimpleCalendarView(), new CalendarModel());
}
static class MyMonthSelector extends MonthSelector {
...
}
}
And it doesn't give me any problems.
Would it be possible for you to post your modified DatePickerDemo to
show us where that exception is coming from?
Thanks,
Isaac
On Thu, Sep 25, 2008 at 9:22 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>> The same error occurs when I extend the MonthSelector. Please verify
>> this?
>
> I will see if I can get it to repro, thanks!
>
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > > The same error occurs when I extend the MonthSelector. Please verify > this? I will see if I can get it to repro, thanks! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
I made a little mistake in my last post above. I am not extending the DatePickerComponent as I write above, as you can also see in the example code and the text below it. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
I am extending the DatePickerComponent directly, as the MonthSelector
isn't very usable.
I have added the implementation for setAllowableDateRange() as I only
want people to be able to select years.
I am extending the SimpleMonthSelector:
public class MyMonthSelector extends SimpleMonthSelector {
The same error occurs when I extend the MonthSelector. Please verify
this?
I do get this error:
[ERROR] Uncaught exception escaped
java.lang.IllegalAccessError: tried to access class
com.google.gwt.widgetideas.datepicker.client.DatePickerComponent from
class com.google.gwt.demos.datepicker.client.DatePickerDemo
$MyMonthSelector
at com.google.gwt.demos.datepicker.client.DatePickerDemo
$MyMonthSelector.access$0(DatePickerDemo.java:1)
at com.google.gwt.demos.datepicker.client.DatePickerDemo
$MyMonthSelector$2.onClick(DatePickerDemo.java:404)
at
com.google.gwt.user.client.ui.ClickListenerCollection.fireClick(ClickListenerCollection.java:
34)
I think in general the DatePicker should be made more usable. Here are
a few things I don't understand:
- I am not allowed to use the DatePicker.Styles class. Why not ? As I
want to use it in my own selector just like happens in the
SimpleMonthSelector.
- The SimpleMonthSelector isn't usable. The method should be splitup
in smaller protected methods such that this functionality can be used
and the subclass can compose his own functionality. I am case I need
to only change the listeners but those are set in the setup, such that
I need to override the whole setup, but I need the other functionality
in setup for the buttons and stuff and the styles, especially as this
latter one is needed as I can't access the Style class (previous
point).
- Why do I need to subclass DatePicker to use my own MonthSelector?...
Why is this DatePicker constructor protected and not public ?
I am thinking about copying the whole DatePicker to my own space as I
can't use it like this :(... but I do want to use it...
-- Ed
On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> Are you extending MonthSelector or DatePickerComponent? MonthSelector is
> public, so if you are extending that, could you create an issue, as that
> should darn well work, though you will have to create a new subclass of
> DatePicker to use your new month selector as well.
>
> On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote:
>
> > Why is the class DatePickerComponent of the DatePicker protected ? I
> > want to add my own MonthSelector, but when I do this, it throws an
> > access exception because this class it protected :(
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Are you extending MonthSelector or DatePickerComponent? MonthSelector is public, so if you are extending that, could you create an issue, as that should darn well work, though you will have to create a new subclass of DatePicker to use your new month selector as well. On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote: > > Why is the class DatePickerComponent of the DatePicker protected ? I > want to add my own MonthSelector, but when I do this, it throws an > access exception because this class it protected :( > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
