User tests: Successful: Unsuccessful:
As most of the javascripts are now based on jQuery some calls to load mootools framework are redundant.
This is a response to #4473
This PR removes it from
formvalidate https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php#L151
combobox https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php#L215
tooltip https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php#L257
modal https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php#L326
noframes https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php#L701
The only case I left the moo tools framework is for tree.
B/C
Shouldn’t break something, as the scripts are NOT moo tools dependent.
Test
Try different navigation on a site (admin will be easier) and check that form validate, compobox, tooltip, modal and noframes still function as usual. Please check 3PD code with this, let’s NOT break things here!!!
EDIT
Except libraries/joomla/cms/html/behavior.php
I found out that toolbar is always loading mootools, for no particular reason so removed it from the files confirm, standard, help in libraries/joomla/cms/toolbar/button
Also almost all backend views have a basic check for the form where the code expects mootools
document.id('banner-form’)
This can be done also with vanilla document.getElementById('banner-form’)
So most of the changes are document.id -> document.getElementById
Thanks @fedik for the heads up!!!
Labels |
Added:
?
|
@wilsonge Thanks for the unit tests code About tooltips: Yes something funny happening there I think is got to do with this code
echo JHtml::tooltipText('COM_CHECKIN_FILTER_SEARCH_DESC’);
Which I think is useless, just a class and a JText::_(’TOOLTIP_TEXT’); is all needed.
I am investigating the (spaghetti code) and hopefully I’ll come up with some changes…
The thing is that you can call tooltips in 2 ways:
JHtml::('bootstrap.tooltip');
And
JHtml::('behavior.tooltip');
The last one needs mootools (legacy staff), but is not used in admin or front end any more...
Category | ⇒ | JavaScript |
Travis fails here JHtmlBehaviorTest::testTooltip and here JHtmlBehaviorTest::testNoFrames
But I guess he still expects to find mootools or he doesn’t like jQuery…
First of all don’t be afraid of the number of files this PR touches.
The changes in all files are straight forward and are grouped in two categories:
remove unnecessary calls JHtml::_('behavior.framework’);
in
libraries/cms/html/behavior.php
libraries/cms/toolbar/button/confirm.php
libraries/cms/toolbar/button/help.php
libraries/cms/toolbar/button/standard.php
But also adding the call, for the time being, at layouts/joomla/toolbar/base.php for not breaking B/C
replace all the document.id(’some-form’)
in edit views in administrator with native javascript document.getElementById(’some-form’)
as suggested by @fedik
Update the ut tests/unit/suites/libraries/cms/html/JHtmlBehaviorTest.php. @wilsonge Thanks for that!!
So although many changes applied the functionality remains the same, but this will ease our way to drop mootools down the road…
@dgt41 you mean this #L56-L86 ?
yes there a lot mootools
vanilla will be a bit complicated there, but jQuery should be good
and maybe better make this in separate pull, cause there need not a trivial changes
At least mootools is properly called here https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_menus/views/item/tmpl/edit.php#L15 so no rush to drop that, yet!
Update as more tests was conducted:
On behavior.php there are some calls to mootools except from the JHtml_(‘behavior.framework’);
the first flag true should be false in these occasions:
https://github.com/dgt41/joomla-cms/blob/mootools/libraries/cms/html/behavior.php#L215
https://github.com/dgt41/joomla-cms/blob/mootools/libraries/cms/html/behavior.php#L651
and
https://github.com/dgt41/joomla-cms/blob/mootools/libraries/cms/html/behavior.php#L394
The last one multiselect uses mootools code for the initialization call
"window.addEvent('domready', function() {
new Joomla.JMultiSelect('" . $id . "');
});”
which obviously has to become jquery (or vanilla)
On Global Configuration is mootools-more and mootools-core still loaded
Yes, which is correct because there is a modal window there, and modal is a mootools script. Unless somebody comes up with new code for modal.js there is nothing more that we can do about it.
PS the modal in @: Offline Image on the select button
do you know the code to show mootools-core. Because its also loaded on sysinfo, I can't find the mootools loading
You can comment this line dgt41@4ce723d#diff-22d356c612b1a6ccbefdcdd05cd81a88R12
But this will most probably break all third party components.
In most pages motools load because of the toolbar buttons removing that will break B/C
No, we don’t want to totally remove mootools. Basically this is a clean up and preparing the code for jquery. But even if I provide all the code that is needed for core components, mootools unfortunately cannot go away because almost all code from 3PD is still using it. This is not a way to TOTALLY REMOVE mootools as this cannot be done in 3.x. But will ease the way for 4.x. And yes it should be 100% safe.
Closing this one, as I break it to two separate and easier to review PRs.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-10-21 14:58:02 |
Tests are failing as the required framework is absent, some help here will be nice ;)