Multiple javascript frameworks included in pages

[GoogleCodeExporter]

Adding javascript to the actions kills the notations format changes e.g. 

<#assign title>GlycoBase</#assign>
<#import "/template/lib/Eurocarb.lib.ftl" as ecdb />

<@ww.url value="/js/lib/mootools.js" includeParams="none"
id="url_mootools_js"/>
<@ecdb.include_js url="${url_mootools_js}"/>

<#include "/template/common/header.ftl" />

problem with onload events

Original issue reported on code.google.com by matthew....@gmail.com on 3 Jul 2009 at 11:29

[GoogleCodeExporter]

Reading up on this some more, there's no easy way for us to fix the clash 
between libraries. We shouldn't be 
using more than one framework (as is, we have a core dependency on MochiKit and 
YUI components). We really 
need a compelling reason to include jquery and mootools. Are there any widgets 
we can't find in YUI, but are 
available in mootools/jquery?

Original comment by hir...@gmail.com on 4 Jul 2009 at 9:58

• Changed title: Multiple javascript frameworks included in pages
• Added labels: Module-UI, Aspect-Maintainability

[GoogleCodeExporter]

What about using "jQuery.noConflict();", this prevents JQuery from killing the 
notation format changes introduced by the other frameworks.  I'm using JQuery 
to 
create modal notification dialog box's.  Within my SVN branch there's therefore 
a 
requirement for JQuery; use this branch to see what affect JQuery has on the 
correct 
functioning of the web application.  As yet I've not seen anything 
rendering/functioning incorrectly.

Obviously if we have an existing framework included that already does what we 
want, 
then that should be used.  In this case I just couldn't get YUI-Panel to behave 
correctly without using an iFrame (which was tricky to use, because I wouldn't 
to 
mess with the iFrames DOM).

Original comment by Damerel...@googlemail.com on 5 Jan 2010 at 1:16

[GoogleCodeExporter]

In the past 6 months or so, I think it's become pretty clear that MochiKit 
development has stalled, which is a 
huge pity. So, for the javascript frameworks - I'd go with jQuery (which, last 
time I checked was the most 
"popular") in the no conflict mode. An adaptor will then need to be written 
between MochiKit and jQuery, and 
then we can retire the MochiKit dependency. The tricky part here is getting the 
event code working with jQuery, 
as jQuery is a DOM-bound framework, and its event-firing mechanism is tied to 
elements. The simple way 
around this is to wrap all our custom objects in the jQuery object wrapper 
before appending events to them.

Original comment by hir...@gmail.com on 5 Jan 2010 at 3:43