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 > > Wauuuuaaa 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 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 -~----------~----~----~----~------~----~------~--~---
