Please, please, please stop using mootools

[erwinv]

Hi,

After firing up a 2.1 test server to check for upgrade issues, I found a huge issue with the added JavaScript libraries. Specifically, mootools breaks the standard JavaScript functionality of "for (idx in myArray) …".

This is a known "feature" of mootools (see http://forum.mootools.net/viewtopic.php?id=3769). Their response is to use the mootools-provided Array.forEach or don't use mootools at all.

We use this for-in construct A LOT (as I'm sure do many JavaScript developers) to loop through arrays in some of our Alfresco web client extensions. Changing all occurrences to a mootools-specific construct is just not an option I relish.

More importantly, using any library that BREAKS STANDARD JAVASCRIPT FUNCTIONALITY should be anathema by principal.

Please, please, please, please backport your scripts to STOP using mootools. It is evil, evil, evil.

Thank you.

[dhalupa]

I second that.. Similar question was asked allready (http://forums.alfresco.com/viewtopic.php?t=8039). Unfortunatelly, no answer from Alfresco side. Mootols is also preventing usage of prototype and as a consequence, usage of richfaces ajax framework and some tomahawk components.

[mikeh]

Hi both,

This is where we're stuck between a rock and a hard place…

Mootools was chosen for developing the portlet components (doclist, mySpaces, myTasks, etc.) due to it's very small footprint, excellent performance and ease of use; certainly when compared to the Prototype/Scriptaculous, Dojo and jQuery libraries at the time.

Other UI elements have been (and are currently being) updated to use the mootools library, as historically Alfresco has used somewhat of a mix of Yahoo, Dojo and in-house code which is a situation we'd like to get away from.

The problem with the Javascript Array object being extended is common to most frameworks - certainly using the heavyweight Prototype and Scriptaculous libraries won't make the issue go away. So we're stuck - we can't use jQuery throughout as it isn't as complete as Mootools and we don't like the bloat of Prototype/Scriptaculous.


The only thing I can suggest is that we can look again at jQuery for some of the more commonly extended web client UI, now they've mostly sorted out the dreadful performance issues. Mootools will still be used for the portlets and WCM UIs, but it shouldn't affect custom templates.

It would be useful to know which parts of the web client you need to be mootools-free before we start any investigative work.

Thanks,
Mike

[dhalupa]

Hi Mike,

Thanks for quick answer.. Could you, please, elaborate a little bit what kind of performace issues did you have with prototype. We are intensively using richfaces and tomahawk libraries which are built on prototype and I did not notice any performance issues.
At the moment, we do not have problem with mootols since we do not use portlet components, and preview panel I can live without, therefore it was safe to leave out the reference to mootols. Nevertheless, if ui is being rewritten to use mootols, I guess, we can expect the situation in the future versions where we can not safely turn mootols off. This would really be a shame, not to be able to use richfaces and tomahawk libraries for Alfresco customizations.

Kind regards,

Denis

[erwinv]

In our case, if you could make the Dialog and Wizard frameworks mootools-free, that'd help a lot. Thanks.

[erwinv]

FYI, I was able to replace all for…in instances in our extensions to Array.forEach calls, however:

- The new scripts will not work in 2.0 on MSIE since MSIE does not have native forEach support. (In 2.1, mootools takes this responsibility.)
- I'm still philosophically against using a library that breaks the JavaScript specification.

[dbaran]

Hello,

We are developping a framework to generate dynamically web client from description files. This framework is based on JSF and Ajax4JSF to bring partial page rendering, and it has ability to use Alfresco components likes dialog, wizard and webscript.

Usage of Mootools prevent us to integrate new webscript in our framework, due to incompatibility with Ajax4JSF and RichFaces…