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 <florin@bytenotes.com> 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.
|