Will the prototype based calendar be the default? Will the prototype library be loaded with the jsImports by default? Will I not be able to use $.(..jquery..) any longer but do jQuery(...) instead?
I would appreciate a way (hopefully not too difficult) to not use prototype. I find it unfortunate that click needs to limit itself to a single js library for its basic functionality (calendar being a fundamental widget). I am however thankful for the great effort that goes into click. Thank you. sabob wrote: > > Doesn't look like there is going to be a nice and clear solution here > so we'll have to go with a trade off. > > The prototype based Calendar does look like the nicest of the lot (and > since it supports time the only real option), however if we base the > Calendar on a specific JS library, users will run into problems down > the road. Whether we use JQuery or Prototype there is still the issue > of users wanting to use a different version of that JS library. > > My feeling is that whichever Calendar we use, we should try and have > the JSCalendar plugin as an alternative. That way if users want to use > a specific JS library or version they have the option of switching. I > volunteer to adjust the JSCalendar plugin accordingly. > > kind regards > > bob > > > Malcolm Edgar wrote: >> I have written to the JSCalendar author about changing the GPL to a >> dual license, but I haven't heard back so I presume this option is >> dead in the water. >> >> I think the two options we have going forward to bring back DateField >> functionality. These options are: >> >> http://electronicholas.com/calendar >> >> Pros: >> * has time support >> >> Cons: >> * has prototype dependency, which can impact jquery code >> * large JS includes >> >> http://jqueryui.com/demos/datepicker/ >> >> Pros: >> * looks slick >> * uses jquery library >> >> Cons: >> * has not time support >> * large JS includes >> >> Interested in everyones feedback >> >> regards Malcolm Edgar >> >> On Sun, Apr 19, 2009 at 4:30 AM, florin.g <[email protected]> wrote: >>> >>> I'm a jQuery guy. If I am forced to load prototype for the sake of a >>> calendar, I'll have to make do without the click-extra package. A popup >>> calendar is the single most needed javascript component and in my >>> opinion it should be independent of any framework. >>> >>> Thanks to everyone for the good work. >>> >>> >>> Joseph Schmidt wrote: >>>>> Please note this is a Prototype based Calendar so its claim of only >>>>> 20kb is incorrect. More likely 20kb + 115kb for Prototype. >>>> But Prototype is already required by other Click controls, and >>>> it's in extras anyway. >>> >>> Not saying not to include it. Just providing full disclosure and that >>> we need to be careful with siding with a particular JS framework. >>> >>> For example if you include a Prototype control in your Page and want >>> to use JQuery you are bound to run into incompatibility issues since >>> Prototype have the bad practice of polluting Object. Also both >>> frameworks bind the '$' character. >>> >>> >>>> Besides, if you want to remove Prototype than another base library >>>> needs >>>> to take it's place - e.g. jQuery(cause it's small enough compared to >>>> other solutions) - it doesn't make sense to implement everything by >>>> hand. >>> >>> There are no plans of removing the Prototype controls however we need >>> to be careful because we are forcing the Prototype framework onto users. >>> >>> My own feeling is that its better to host specific JS framework >>> controls in ClickClick like was done with JQuery. >>> >>> regards >>> >>> bob >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://n2.nabble.com/A-very-good-Calendar-replacement-%28MIT-license%29-tp2651408p2656713.html >>> Sent from the click-development mailing list archive at Nabble.com. >>> >>> >> > > > -- View this message in context: http://n2.nabble.com/A-very-good-Calendar-replacement-%28MIT-license%29-tp2651408p2692917.html Sent from the click-development mailing list archive at Nabble.com.
