I checked out the latest SVN trunk of qooxdoo and now i have the following problems:
Some events seems that they are not comming through
Virtual Lists are not filled anymore (the _createWidget() method of the extension from qx.ui.virtual.cell.AbstractWidget is not called)
My original version was QX 1.0.1-pre and the problems appeared also when i tried to migrate to 1.2
Just to get the obvious stuff out of the way, did you follow the steps of the migration guide and make any necessary changes outlined in migration.log?
Aside from that, the virtual widgets are still experimental and no migration path is provided, meaning you'll have to go over your code and check if the parts of the ui.virtual API you're using have changed since 1.0.1.
For the missing events, please provide some more information: What events are you listening for?
The problem with the event seems to be a bug in Qooxdoo
Related
I'm trying to get the Watson Visual Recognition to run client side by using express-browserify with reference to the node-sdk for watson-developer-cloud. The VisualRecognitionV3 makes use of the fs package hence I get the fs.existsSync error when I'm trying to call it from the client-side as the browser doesn't know which filesystem to use. My question is how do I go about creating a so called 'abstraction layer' as I am restricted to using the express-browserify package for cross origin calls.
This thread is pretty helpful in shedding some light but I'm not sure where to start regarding the 'abstraction layer' or if there are any other solutions. Also, would something like socket.io work for this? I've linked a clone of the directory here as it seems less clunky than pasting the multiple portions below.
The repository can be cloned and just requires a personal iam_apikey with relevant launch configuration. Appreciate any pointers. Thanks!
I didn't manage to sort this out with express-browserify due to the require(fs) from browser issue but I was able to get it running using the express-ws package
I've working on modification of the 'shoutem.notification-center' extension using as a guide this tutorial and I'm having some issues.
At first I tried to use the Extend the extension approach, but like I've posted on this issue, didn't quite work.
So I've tried the Directly modify approach, which works fine on my local phone, but once I use the command shoutem push to send my modifications to the server, the instance on Appetize never stops the 'Building your application' message.
The major problem is that there's no error code or feedback.
That was not the first time that happened, I had the same issue modifying other extensions. Any idea why this is happening?
The issue is likely one of two things.
New native dependencies were added that the Builder preview cannot process due to it's predefined binary.
Your directly modified extension works locally, but not on the Builder because locally it's path is still AppName/extensions/shoutem.extName, but on the Builder it's AppName/extensions/yourDevName.extName, so it fails.
The first one can be resolved by either using a non-native solution as a replacement for the native dependency you were using, or to simply use a local emulator for previewing purposes.
The second can be resolved by making sure all extensions that reference the one you directly modified are edited to now reference your new directly modified extension instead of shoutem.extName.
If you could shoot me your app ID in a comment I can let you know which one it is and what the best steps to fix it would be.
I am after something like
firefox['update'] = "never" equivalent in cookbook recipe for firefox as auto updates is causing issues with selenium tests. Could someone please help?
Looking at the attributes provided by the cookbook reveals the following:
default['firefox']['version'] = 'latest'
So setting this to some specific version would be a starting point (not sure if you have set this, as you seem to lack the knowledge how to find the attributes provided by a cookbook.
Regarding actually disabling updates, a quick search revealed this thread, which lists the option that needs to be added to the user.js file in your profile:
user_pref("app.update.enabled", false);
I'm trying to follow the basic cometd example here: http://dojotoolkit.org/reference-guide/1.7/dojox/cometd.html
It's using the old module loader so I tried the equivalent as follows:
require(["dojo/ready","dojo/io/script","dojox/cometd","dojox/cometd/callbackPollTransport"], function(ready, dontcare, cometd) {
ready(function(){
cometd.init('http://localhost:8080/MyCometD/cometd');
comted.subscribe("/test", function(msg){
console.debug(msg);
});
});
});
This doesn't work and I think it has to do with loading modules - there is some sort of silent error as the code within the ready function does not execute at all. What I found is that when the "dojox/cometd" require statement is present, the code within the ready function does not execute.
Running example: http://jsfiddle.net/Q9W8f/2/
Example with dojox/comted removed: http://jsfiddle.net/mMs2h/4/
I haven't worked with the new module loader that much so I bet I just have some simple misconception.
Help!
It seems like youre correct and that there is a 'wait-loop' for a module requirement that never gets loaded. This may be any of the requirements inside dojox.cometd and you'd need to rewrite the codebase for a fix.
I have had similar issue with the RollingListPane, also in dojox repository - and the developers are saying 'we are 100% AMD compliant with 1.7' however the X in dojox is short for experimental. The developement of dojox modules is not done by the core djtk team and there are still glitches..
Try for starters to avoid using CDN which has performed a >>built macro on every single module. This tends to fail at times whilst using AMD. Instead download the tarball and use a local copy - Not compressed (dojo-release-1.7.2-src)
You can find the hello world example in cometD and ExtJs at following link:
http://jksnu.blogspot.in/2013/08/network-reliability-by-cometd-hellow_16.html
I need to integrate a .net2.0 app with nservicebus. Actually, I just need that this .net2.0 sends a message to a nservicebus queue.
Should I just create it by myself?
Theres any trick I should watch out, so when I upgrade to, lets say, nservicebus4 it wont break ?
using .net 2.0 will be a problem with trying to reference nservicebus. i don't think there is any straightforward way to reference nservicebus from a 2.0 application (outside of using a very old version, which would have problems too).
the shortest path would probably be to upgrade the framework version to 4.0. why not just do this? if you're talking about making changes and sending messages, you must have access to the source code and the ability to change it.
next after that might be to serialize a message yourself and send it with system.messaging. i think this is what you mean by "create it by myself." you'd definitely want to test that your messages still work if updating to another version of nservicebus on the handling side. udi is insistent on backward compatibility in updating versions of software, so i'd expect nservicebus would exhibit this probably and that your messages would still work, but you would want to make sure.
To "integrate" an app with NServiceBus simply include binary references to NServiceBus.dll, NServiceBus.Core.dll, and NServiceBus.Host.exe in your solution.
Try downloading the samples.