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.
