[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Ajax libraries: let's wait a bit
From:       Andreas Hochsteger <e9625392 () student ! tuwien ! ac ! at>
Date:       2005-11-08 6:07:51
Message-ID: 437040B7.2060005 () student ! tuwien ! ac ! at
[Download RAW message or body]

Hi Sylvain and other AJAX gurus ;-)

I wonder, if you heard of Taconite [1] which seems to have released 1.0 
recently?
It is licensed under the Apache License, but I don't know, if it does 
what we need.

Additionally to the list of AJAX libraries already posted [2] I found an 
other one in [3].
But unfortunately Taconite isn't mentioned in both lists.

Cheers,
Andreas

[1] http://taconite.sourceforge.net/
[2] http://wiki.osafoundation.org/bin/view/Projects/AjaxLibraries
[3] http://ajaxpatterns.org/Ajax_Frameworks

Sylvain Wallez wrote:
> Hi all,
> 
> A few days ago, I raised some concerns [1] about the Scriptaculous 
> JavaScript library which we started to use in the Ajax block, because of 
> modifications made to JavaScript base classes made by the underlying 
> Prototype library on which it is based.
> 
> I had no satisfying answer on the Scriptaculous mailing-list, and 
> removing the base classes extensions in Prototype would mean rewriting a 
> lot of things in Scriptaculous and is thus very unlikely to happen. 
> Furthermore, I also wanted to use the Sortable [2] class for CForms 
> repeaters, but had to make important modifications to the class itself 
> for this to work with CForms because the conventions used are different.
> 
> Considering this, I decided that Scriptaculous was a wrong choice and 
> looked to other alternatives.
> 
> The most promising so far is the Dojo Toolkit [3] :
> - it has a very cool "load on demand" feature that allows to have only 
> bootstrap <script> tags in the page, and then load other scripts when 
> they are needed using "require('foo.bar.baz')". A must have in Cocoon 
> where each block may bring its own client-side scripts. Also in CForms 
> where you do not want e.g. to have htmlarea and calendar loaded in all 
> pages if not used in these pages.
> - it is not only about cool effects: it provides a number of data 
> structures, can use iframes when xmlhttprequest is not present, tackles 
> the browser history problem in Ajax apps, etc.
> - its development is community-driven, even if the original creator 
> plays the "benevolent dictator"
> - it has an interesting test system that uses Rhino, and the ability to 
> assemble and compress a number of files in a single one to speedup 
> things in production.
> 
> The current drawback of Dojo is that the all the spiffy effects are 
> there (and more [4]), but lack a close integration with background page 
> update. But that should be a couple of classes.
> 
> All this to say that before making a choice for a client-side JS library 
> that more and more blocks are likely to use with the progression of Ajax 
> needs, we need to take a bit of time to find the pros and cons of the 
> various alternatives.
> 
> As 2.1.8 will be released soon, I will rollback changes to the CForms JS 
> library so that is uses the little home-grown stuff I wrote back in 
> July. I will also remove the Ajax examples that rely on Scriptaculous 
> (sorry Jeremy!), which will be reinstalled once we've taken the time to 
> make a choice.
> 
> Thoughts?
> 
> Sylvain
> 
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112921787207346&w=2
> [2] http://script.aculo.us/demos/ajax/sortable_elements
> [3] http://dojotoolkit.org/
> [4] 
> http://dojotoolkit.org/~alex/dojo/trunk/tests/widget/test_FisheyeList.html
> 
[prev in list] [next in list] [prev in thread] [next in thread]