> > Sorry, could have sworn that was public. Btw., DatePicker is littered with > direct uses of the calendar field. If getCalendarView() is protected, we > should always call it. > > Still, the amount of duplication btw. the DatePicker API and CalendarView > is odd. Can CalendarView be reduced to a smaller set of "primitive" calls at > all? E.g., it doesn't really need the setDatesEnabled convenience wrapper, > DatePicker can be in charge of that kind thing. >
Sure, we can get rid of the convinience methods. So what is the actual date returned in such a case? The first day of the month(s) displayed? Or can a Date be filled with null day info? Sounds like another excellent javadoc opportunity. Yep. Also, I think it does make sense to extend this API down to the calendar model level, as that would probably help mitigate the confusion. > > Anyway, can such a CalendarView really be implemented? CalendarModel seems > very locked down to a single month. > >> The calendar view specifies a month at a time, the calendar view can increment the month to help it fill in its date views. > That might not be possible--the compiler may find itself unable to tell > whether to use the Date or the Date... version. > Yep, and if we actually implement ".." efficiently in our compiler, no reason to do this either! > >> > February is visible. The 10th is disabled. The user moves the picker to > March, and back to February. What is the state of Feb. 10? > It is no longer disabled. That's why the API has the assertion actually, as all the api calls that include "visible dates" specifically are reset when the date picker refreshes. > Custom CalendarView seems okay, but MonthSelector is an empty class, and > its default implementation is final. So I have protected API that says "your > month selector here," and no way to actually provide one without copying and > pasting our code. That seems inconsistent. > >> So you think we should include an extendable month selector as well? We actually even have a googler working on one, so we can see how far he has gotten or create one ourselves if he hasn't gotten far enough. > >>> CalendarUtil.java >>> >>> Some of the methods in this public class are not public, seemingly >>> arbitrarily. Is there a real reason we don't want people to call isWeekend >>> or hasTime? Why is resetTime private? >>> >>> >> We were trying to expose only the methods we were absolutely certain other >> people would want, mostely because we used them ourselves, rather then >> exposing all of them. >> > > If we have methods we aren't using, why are they there? > We are using them for calendar model, we just don't know if anyone else would need to use them. > >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
