You could also make a repo on Github :) Of course that would require you to know Git, but you got to host the code somewhere at some point :)
On Oct 27, 1:39 pm, Daniel Lohse <[email protected]> wrote: > No, not at the moment, I'm sorry. :) > > I'm a little over 100 lines of code now, I think I'll post what I have > to a MooShell soon. > Maybe someone wants to use that "Update" button on MooShell and > collaborate with me? > Just kidding but could be an interesting thing to do with MooShell, > now that it supports versioning. :) > > Do you have anything to add to my lengthy post? Suggestions always > welcome! > > Cheers, Daniel > > On 2009-10-27, at 27/October, 2:28 PM, vladyn wrote: > > > > > > > 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!
