click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: A very good Calendar replacement (MIT license)
Date Sat, 25 Apr 2009 04:08:51 GMT
How about for DateField we use CalendarDateSelect (prototype), as this
provide closest feature set to the previous control.  The prototype
import would only be included for this control, it wouldn't be
included in the extras JS import.

In addition we could include an extras jquery package including
Datepicker control, and also include some of the other jquery
controls, e.g.

Accordion
Dialog
Progressbar
Slider
Tabs

regards Malcolm Edgar

On Sat, Apr 25, 2009 at 12:51 AM, florin.g <florin@bytenotes.com> wrote:
>
> 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.
>
>

Mime
View raw message