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