can this be seen in action somewhere ? sounds really cool
On Oct 14, 5:42 pm, Annis McKenzie <[email protected]> wrote: > Hello folks, > > I know that the title is very misleading because I don't actually have > something to show to you at the moment (no, not one line of code! :)). > > Nevertheless, here goes: I've resently had the need for a more > advanced calendar solution, have used Aeron Glemann's "Calendar" in > the past and also tried the new kid on the block, the Monkeyphysics's > "DatePicker". > > What I liked about the Calendar was its multi-calendar ability. But > over the last few days, a few bugs made me investigate and it's not > pretty: it's still mostly a MooTools 1.11 component and the code is > not as clean and extensible as I'd like. Just one bug: the multi- > calendar ability governs more than one calendar and keeps them in > chronological order but when you're in the same month and select a > date in the first calendar, switch to the second calendar, you can > still select a date before the first calendar's date. The component > then back-dates the first calendar and that I don't like. But > sometimes (don't know when) it correctly disables the dates before the > first calendar's displayed date. Weird stuff. > > So, I thought I'd try the DatePicker. Well, no multi-calendar ability > which is kind of a bummer. > > Here's the workflow I'd like to implement and which I think should be > used for all date-range pickers in the whole universe (:P): > 1. select a date in the first calendar > 2. on opening the second calendar it opens in the same year and month > as the first calendar's date (usability). The date of the first > calendar is marked and I cannot select dates before that date. > 3. After selecting a date in the second calendar I want to change the > first date and I select a date that's after the second calendar's > date. The second calendar responds by keeping the date difference that > existed before I changed the first calendar's date. > > Example 1: > first calendar: 2009/10/02 > second calendar: 2009/10/10 > > then: > first calendar: 2009/10/04 > second calendar: 2009/10/12 > > AND: > first calendar: 2009/10/02 > second calendar: 2009/10/10 > > then: > first calendar: 2009/10/12 > second calendar: 2009/10/20 > > BUT: > first calendar: 2009/10/02 > second calendar: 2009/10/10 > > then: > first calendar: 2009/10/01 > second calendar: 2009/10/10 > > So the second calendar's date only changes when the first calendar's > date is changed to a later date. > > I hope you're still following me after all these "first calendar, > second calendar" phrases. > > Now, there's more: I want it to be a MooTools 1.2 component. There > should be a base calendar, I'll call it MooCalendar for now. Then > there should be several inheriting calendars: MooCalendar.Inline (the > calendar is not only shown when clicking inside a text field but is > visible all the time), MooCalendar.Multi (yeah, guess what, multiple > linked calendars, updating chronologically) and > MooCalendar.MultiInline (MooCalendar.Multi, but shown all the time). > It should also implement real events and not, like in the DatePicker's > case, call this.options.onSelect() which is, to my mind, so un-Moo-ish > as it can get (is that even a word? :)). *rant over* > > Now, a few options/abilities: > - do not close on selecting a date but instead mark the date range and > all the dates in between (think Google Analytics) > - updateable by updating the text field the calendar is bound to > (having nothing weird to do when one wants to select another date > externally) > - works with simple text inputs and select boxes (either 3 select > boxes for the year, month, and day or combined somehow like 1 year > select and 1 select for month and day combined) > - maybe even allowing multiple selections (even multiple date-range > selections) > - small filesize (when I don't need multiple calendars, why do I have > to carry that weight around on every page?) > - EASILY localizable! No calendar I know has that and I don't mean > that I can change the month names when I instantiate the damn thing, I > mean really easy localizable, so I can change the language by, for > instance, giving the input element a new class "calLang:'de'" to ease > the integration into CMS and not having to include separate JavaScript > files. That is not easy as it is today. *phew* > > Using MooTools More should make input/output dates with customizable > formats considerably easier (MooTools More Date and Date.Extra come to > mind). And localization. :) Thanks, MooTools guys! > > I hope I did not tread on anyone's toes by posting this. Okay, now I > only have to implement all of the above. > > What I wanted to ask the community here, before I really start: Do you > know of any *essential* features that the base calendar should > implement? Or, for that matter, do you know another inheriting class > that you'd like to see and that has other unique features? > > Short posts of lists or links to sites that implement such a calendar/ > specific feature should suffice. :) > > Thanks and wish me luck, I think this won't be an easy thing to do. > I'l start as soon as I have a broader picture of what I missed here > that could be necessary in planning and developing this. So, shoot! :) > > Daniel > > PS: One more thing. Time and year picking should be added by using > Class.refactor and not implemented as inheriting classes because I > want the base calendar to be as lean as possible. Or are there other > suggestions regarding this? > PPS: License? Yes, MIT! :) > PPPS: Could this be added to MooTools More? :D Just kidding but always > think big, I say!
