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