Up till now my system used dojo 1.3.2 successfully. I have many Javascript files with our own declared classes which are combined together using shrinksafe to a single Javascript file.
I tried to upgrade to dojo 1.4.x (I tried several minor versions). I used the build system with a layer file with all the dojo.require()'s I use (the same one I used to build the 1.3.2 version.). The build process seems to be successful.
Unfortunately, I cannot succeed in bringing the system on the air. Firebug throws exceptions such as ... is not a constructor for my declared classes, and mixin #0 is null.
Please help !
These error point to 2 things:
1) Make sure you have a full src build of dojo.
2) The signature of dojo.declare changed in 1.4:
previously you will probably have had the following declaration for a class with no inheritance:
dojo.declare("myNamespace.classA", [], {...
In 1.4 the empty array of inherited classes will break a custom build. You should upgrade your code to the new signature of dojo.declare:
dojo.declare("myNamespace.classA", null, {...
Related
Actually I've two questions, because the common workaround for my initial problem does not work :)
I'm trying to build an Emscripten based library which calls JavaScript functions as described here: https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#implement-a-c-api-in-javascript
Simply put I just implement my C/C++ code against a C-Function, implement that function in a .js file and 'link' that file using --js-library.
Basically things are working for me except with version EMSDK version 1.38.12 I got a warning when linking the final library:
warning: undefined symbol: foo_
.. which I don't understand but I could just ignore it. In newer versions of EMSDK the behavior changed and the warnings become errors.
Searching for this error you find you can just add -s ERROR_ON_UNDEFINED_SYMBOLS=0 when linking, but this doesn't work (for me) - I still get this error despite I can see this option being added to the linker.
So my questions are:
how do I make -s ERROR_ON_UNDEFINED_SYMBOLS=0 work for me?
and why do I get this warning in the first place? how do I get rid of it?
I'm trying to get loadIntoLocation working, but I keep get the error message,
Property 'loadIntoLocation' does not exist on type 'DynamicComponentLoader'.
I've looked at other examples and used plunker and it works there, but I can't seem to get it working locally. I grep'd the Angular2 core and could not find any mention of a loadIntoLocation function.
How do I find out what version of angular2 I'm using? Can I upgrade? I just used npm install to deploy my environment.
That was removed a while ago as far as I remember. DynamicComponentLoader is deprecated anyway. Use ViewContainerRef.createComponent() instead.
For a full example see Angular 2 dynamic tabs with user-click chosen components
I use SignalR 2.2.0 in a MVC5 project. SignalR depends of JQuery in client-side.
JQuery recently released new version, I updated it from Nuget, specifically from version 2.2.4 to 3.0.0.1, but then SignalR stopped working. Startup command "$.connection.hub" in javascript fails.
After a long time head scratching, I downgrade JQuery to 2.2.4 and everything is fine again.
Am I the only one getting this problem? There is any workaround?
Thanks.
You must edit the signalR code by yourself, In jquery 3 they removed the shortcut for load event :
Breaking change: .load(), .unload(), and .error() removed
These methods are shortcuts for event operations, but had several API
limitations. The event .load() method conflicted with the ajax .load()
method. The .error() method could not be used with window.onerror
because of the way the DOM method is defined. If you need to attach
events by these names, use the .on() method, e.g. change
$("img").load(fn) to $(img).on("load", fn).
https://jquery.com/upgrade-guide/3.0/
so in the file jquery.signalR-{version}.js :
you must update this line :
_pageWindow.load(function () { _pageLoaded = true; });
To :
_pageWindow.on("load",function () { _pageLoaded = true; });
Finally version 2.2.1 of SignalR was released, solving this problem. Thanks for all comments.
If you're still getting errors like this after updating to 2.2.1 and jQuery 3.x then read on...
TypeError: Cannot read property 'client' of undefined
Like I am you are probably using the dynamically generated proxy, and you checked your /signalr/hubs file and found you don't have any proxies defined.
var proxies = {};
Wait you may ask I didn't change anything - where did they go?
Well, like me you probably were in such a hurry to upgrade signalR to 2.2.1 that you forgot to do it in all your projects and now you are using both 2.2.1 and 2.2.0 in different assemblies. (I am defining my hubs in a different assembly than my main app).
All I needed to do was make sure I had the latest nuget package version in every project and it all worked. Should work fine after rebuilding. If not, this may also help.
Also do yourself a favor and read the jQuery 3 upgrade guide if you use much jQuery elsewhere.
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
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);
});
});
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,
Installed CiviCRM in a fresh Drupal install, customized the CiviCRM and added data. The actual Drupal site was built separately in a separate install. Now that it is complete, I merged the CiviCRM with the new Drupal Site (files and database). Everything appears to work except when logged into CiviCRM: http://example.com/civicrm/dashboard it says:
"Javascript must be enabled in your browser in order to use the dashboard features."
And yes Javascript is enabled. The CiviCRM Menu is all broken and such. Chrome also reports the following errors:
Uncaught TypeError: Object # has no method 'menu'
jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'
main.js:6Uncaught TypeError: Object # has no method 'cycle'
jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'
Javascript compression under performance is not enabled. Any ideas?
CiviCRM uses the jQuery object as cj instead of $ in order to avoid conflicts with the Drupal JQuery library. In theory, they are fine using different versions because they are namespaced differently (which jQuery supports officially using noConflict()).
The conflict you have probably comes from your modifications causing either Drupal or CiviCRM to load its jQuery library at a different point in the bootstrap, or making it try to load jQuery more than once. This would make the operation to convert $ into cj pick up the Drupal jQuery object after it has already been instantiated, rather than before, leaving Drupal and/or CiviCRM without the libraries it needs being attached to the $ object (are you using # instead of $?).
Search for all code that uses noConflict() everywhere on the page in question and its JavaScript includes. You should only find it in one place. Compare with the demo.civicrm.org pages to see the difference and you'll probably find an extra one in there somewhere. Best hope for fixing it is to adjust the load order of your custom modules in the Drupal system table, or else set the second noConflict() call to run conditionally on there not being a cj object already.
I've completed a bug report. Applying this patch resolved the problem for me in a seemingly clean way. This way the jQuery library does not get loaded more than once if not necessary.