Mailing-List: contact click-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: click-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 lists+1222975813951-1134974@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Message-ID: <1240584666695-2692917.post@n2.nabble.com>
Date: Fri, 24 Apr 2009 07:51:06 -0700 (PDT)
From: "florin.g" <florin@bytenotes.com>
To: click-dev@incubator.apache.org
Subject: Re: A very good Calendar replacement (MIT license)
In-Reply-To: <49EF6C52.1060309@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <gsa730$5pq$1@ger.gmane.org>
 <525d8e10904180249l59f97f95id7741e508778b248@mail.gmail.com>
 <49E9FC32.30901@gmail.com> <gscva0$p1a$1@ger.gmane.org>
 <49EA0A16.8050007@gmail.com> <1240079412827-2656713.post@n2.nabble.com>
 <525d8e10904212323j66f06338n3b355e2e494413f5@mail.gmail.com>
 <49EF6C52.1060309@gmail.com>


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.