YUI Version Conflict Issue in Portlet

问题

I'm loading yui.js 3.3.0 version file from portlet but liferay its using 3.2.0 yui.js file, so whenever i'm loading that page js errors are coming like

G_ENV._loaded[VERSION] is undefined - this error is coming in yui.js which is liferay using that is 3.2.0 version.

so its replacing value like G_ENV._loaded[3.2.0] and that will throw an error becoz we loaded 3.3.0 version from portlet.

I replaced yui.js 3.2.0 version file in portlet but It was throwing some other js errors.

How will it work same in 3.2.0 or Is there any way to update existing version of yui?

This is the code of yui.js in this line its throwing error

                      if (!G_ENV._loaded[VERSION][name]) {
                            missing.push(name);
                        } else {
                            used[name] = true; // probably css
                        }

Any help would be appricated, anyone has faced this kind of problem.

Thanks

回答1:

Upgrading, changing, or overwriting the native YUI installation in Liferay is extremely difficult, because of two reasons. One, Liferay 6.0's UI framework (Alloy) runs on YUI 3.2.0. Two, the native portal template instantiates alloy ui onto the global YUI object (YUI.AUI), which is awful, as it makes the YUI framework tightly coupled to the horrifically implemented AUI. Your browser calls this AUI reference, on the YUI object, as the page is loading and after the window.onload event. If you try to replace or modify the global YUI object, it screws up Alloy, which Liferay's UI runs on.

Since upgrading is out of the question, the next best alternative is to bring in just the new YUI modules you want to use. Also, you could try out Liferay 6.1 CE, which has 3.4.1 built in, but it looks like its still in beta testing.

Here's an example of bringing in and using the dom-core module from YUI 3.4.1 and using it in Liferay 6, which runs on YUI 3.2.0. I got the idea from YUI's docs on how to bring YUI 2 modules into 3 (http://yuilibrary.com/yui/docs/yui/yui-loader-ext.html). To quickly figure out dependencies each module has, you can use YUI's online configurator http://yuilibrary.com/yui/configurator/.

var config = {
ignore : ["skin-sam-overlay","skin-sam-widget","skin-sam-widget-stack","skin-sam-tabview"],
groups: {
    yui341: {
        base: '/js/yui-3.4.1/build/',
        modules:  {
            yui341_yui_base: {
                path: 'yui-base/yui-base.js'
            },
            yui341_oop: {
                path: 'oop/oop.js',
                requires: ['yui341_yui_base']
            },
            yui341_features: {
                path: 'features/features.js',
                requires: ['yui341_yui_base']
            },
            yui341_dom_core: {
                path: 'dom-core/dom-core.js',
                requires: ['yui341_yui_base','yui341_oop','yui341_features']
            }
        }
    }
}
};

YUI(config).use('yui341_dom_core',function(Y){
    //YUI 3.4.1 config modules are now accessable through 'use' call
    console.log(Y.version);  //say hello to the newer version (3.4.1)
    Y.use('dom-core',function(Y){
        //Finally have access to native 3.4.1 module
        console.log(Y.DOM);
    });
});

回答2:

Actually, the problem isn't because of Alloy being shoved onto the YUI object. That would be fairly trivial to work around by just simply doing: YUI.AUI = AUI after loading the new YUI.

The problem is because of everywhere Alloy (and even YUI modules already loaded on the page) references YUI, it expects it to be a specific version of YUI.

In many cases, this isn't that big of a deal, as the API between YUI releases isn't that far off. However, between 3.2 and 3.3 there were some changes in Widget, as well as other general changes that could cause problems.

The issue is that YUI currently doesn't have an acceptable way to load multiple versions of the library onto the page that won't cause some sort of conflict. (Because the YUI global get's overwritten, as well as it's properties, such as YUI.Env).

However, I have been kicking around an idea for one possible way to handle this, using dynamically generated iframes to load a separate YUI instance in a different window and pass it along to the original page).

If I can get that working, it's something that we will be backporting to all versions of Alloy, so that Liferay users can leverage it as well.

Josh, if you have any thoughts on a better way to handle this, I'd definitely be all ears.

Thanks,

来源：https://stackoverflow.com/questions/7726261/yui-version-conflict-issue-in-portlet

标签

javascript

yui

liferay

portlet