click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <sab...@gmail.com>
Subject Re: A very good Calendar replacement (MIT license)
Date Wed, 22 Apr 2009 19:13:22 GMT
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.
>>
>>
> 


Mime
View raw message