I am using Awesomium with C++ and I'd like to load local pages with AJAX.
Awesomium is running on the chrome engine as far as I know, and chrome has disabled loading local files through ajax calls.
However this can be enabled setting this flag in awesomium config:
WebConfig wc = WebConfig();
wc.additional_options.Push(Awesomium::ToWebString("--allow-file-access-from-files"));
web_core_ = WebCore::Initialize(wc);
I think this is correct?
Source: https://code.google.com/p/chromium/issues/detail?id=40787&q=ajax%20local&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS
Anyway, my AJAX doesn't succeed, it fails and the page does not load.
the ajax:
$.ajax({
type: "GET",
url: u,
context: document.body,
dataType: "html"
}).success(function() {
test("yes");
}).error(function() {
test("no");
});
// prints "no" when the function is called.
Could anyone please point me in the right direction?
I think it should be possible, I've seen others on this site claiming to be using awesomium and ajax calls.
Best regards.
Related
I'm working with ABP IO 4.4.4 and I want to change the default swagger URL by adding a prefix
Eg :
swagger/index.html -> mynewsite/swagger/index.html
I tried the changes mentioned in the post
How do I change the Swagger default URL and use a custom one?
But the swagger documentation and swagger-ui does not seem to load. When I use inspect element in the browser it shows that abp.js is not found (404) and the console log show the same. Any idea on what could be done to make this change. Thanks.
app.UseSwagger(o => {
options.RouteTemplate = "foobar/swagger/{documentName}/swagger.json";
});
app.UseAbpSwaggerUI(options => {
options.RoutePrefix = "foobar";
options.SwaggerEndpoint("/foobar/swagger/v1/swagger.json", "Support APP API");
options.InjectJavascript("/swagger/ui/abp.js");
options.InjectJavascript("/swagger/ui/abp.swagger.js");
});
Whats done here is the the js file abp and abp.swagger.js are loaded again in a relative path. If you chack the Volo.Abp.Swashbuckle wrapper a similar configuration could be found.
I'm trying to move a very old 2.x ember-electron application to new electron with ember-electron and got application window with blank screen and error in console:
(node:9061) electron: Failed to load URL: serve://dist/ with error: ERR_FILE_NOT_FOUND
The calling file ../new-ember-electron/electron-app/src/index.js has lines from old applications:
const emberAppLocation = 'serve://dist';
mainWindow.loadURL(emberAppLocation);
File ../new-ember-electron/app/router.js has:
this.route('index', { path: '/' }, function() {}
Files ../new-ember-electron/app/routes/index.js, ../new-ember-electron/app/controllers/index.js and ../new-ember-electron/app/templates/index.hbs also exist.
So, it's unclear what exactly is not found and how to find a more detailed error (application developer console doesn't have errors). But if to change the mentioned 2 lines in ../new-ember-electron/electron-app/src/index.js to:
const emberAppLocation = '../app/index.html';
mainWindow.loadFile(emberAppLocation);
then application shows content of the correct file, despite nothing working in it, even <LinkTo>...</LinkTo> is not treated as a link.
Would you please help me to understand how an ember-electron application should be structured and which way is called for the recent versions?
Used versions: node - 16.14.0, electron: 17.0.1, ember-cli: 3.28.5, ember-electron: 3.1.0, OS: darwin x64.
Thank you.
Thank you, jacobq, I've looked at your example and used emberAppUrl to start from ember-dist/index.html file. After few more changes related to require/requireNode (fixed with webPreferences options in mainWindow) the app rendered index.html file. But a problem with app location happens again right on {{ content-for "body" }} in index.html: "Uncaught Error: Cannot find module 'app-name/app'" where app-name is the application name set up as 'name' in /package.json and as 'modulePrefix' in config/environment.js. The error itself comes from /node-modules/ember-cli/lib/utilities/ember-app-utils.js, 'contentFor' function called with 'app-boot'. The ember-cli itself constructs the /app-name/app path. So, the question now is what exactly ember-cli expects to find during the boot with the new structure? Or maybe some config variable should be added to let know Ember about the /app-name/app location?
Edited:
jacobq, yes, the only difference in index.html is application name: "testapp". RootURL is set in ../testapp/config/environment.js:
podModulePrefix: 'testapp/pods',
environment,
modulePrefix: 'testapp',
rootURL: process.env.EMBER_CLI_ELECTRON ? '' : '/',
locationType: process.env.EMBER_CLI_ELECTRON ? 'hash' : 'auto',
The full error:
It happens when testapp.js file is called from index.html, on code included from ember-cli:
if (!runningTests) {
require("testapp/app")["default"].create({"LOG_TRANSITIONS":true,"LOG_TRANSITIONS_INTERNAL":true});
}
First thing I'd like to plug is joining the #topic-desktop channel on the Ember.js community Discord server: https://discord.com/channels/480462759797063690/488735754139336714
(it's often easier to work things out by chatting there as there's lower latency than typically found with forum post/reply platforms)
Secondly, there are lots of breaking (but good) changes between ember-electron 2.x and 3.x, so I'd encourage you to work through the upgrade guide here: https://ember-electron.js.org/docs/guides/upgrading
That said, I suspect that the problem you're seeing is related to the change from serve:// to file://. Have a look at the demo app I just spun up here:
https://github.com/jacobq/ember-electron-demo
You can see the new emberAppURL here:
https://github.com/jacobq/ember-electron-demo/blob/cf7c5dee2cd975f8c67ed1dfc61eb717461f5b7d/electron-app/src/index.js#L13
Basically, ember-electron v3.x puts the usual dist output from ember build into <project_root>/electron-app/ember-dist/ now.
FWIW, I'm actually stuck on 3.0.0-beta.2 in my application because I am using IndexedDB and don't have migration code to deal with origin-related issues of switching to file:// scheme. I don't recommend that you use that version, but you could try it if you wanted to see if that changes the error you're encountering (because that beta still uses electron-protocol-serve).
TL;DR: Added custom location type to environment.js then ember serve -> open browser to route /foo -> cannot GET /foo
Followed the instructions at https://www.emberjs.com/api/classes/Ember.Location.html#toc_custom-implementation and copied the code exactly as it appeared into a file called app/locations/history-url-logging.js, added a line to config/environment.js that said:
ENV.locationType = 'history-url-logging';
For reference, the code given in the docs is simply:
import Ember from 'ember';
export default Ember.HistoryLocation.extend({
implementation: 'history-url-logging',
pushState: function (path) {
console.log(path);
this._super.apply(this, arguments);
}
});
I decided to restart the server, did the usual CTRL+C to ember s then did ember s again. I went back to my browser sitting on one of the routes, hit F5, and received the cryptic error:
Cannot GET /contacts
So, after MUCH Googling and trial and error (and posting a previous question here which I just edited with this text you're reading), I discovered that to FIX that error, all I had to do remove the config line ENV.locationType = 'history-url-logging';, restart the server (ember s), and suddenly the app worked fine!
What's even more odd is that if I start the app without that line in environment.js, then once the app is running (and the browser window reloads just fine, etc), then I re-add the line that says ENV.locationType = 'history-url-logging'; (which triggers a live reload), and the app still works fine! (E.g. hitting F5 to reload the page doesn't vie me the "Cannot GET /contacts" (or whatever the route is) error.) And, of course, the console gives me the "console.log" output as expected from the code above.
So, long and short of it, using a custom location totally seems to screw up ember serve - which is really sad and frustrating! Any ideas how to fix this?
Ember built-in server looks at the environment.js locationType property to figure out if it must serve routes after the rootURL path. By default, if the locationType is history it will do it. It uses string matching.
In your case you wrote your own location, inheriting from HistoryLocation therefor the locationType property in the environement.js is now history-url-logging. The built-in server doesn't recognize it as a history based form of location just by the name. It will default to hash location. It doesn't analyze your code.
For this scenario, we have to help the built-in server to understand that the locationType is equivalent to a history location.
You need to add historySupportMiddleware: true in your environment.js file right after the locationType property.
I'm trying to integrate Facebook sharing into a webpage using this code edited from their official developer tutorial, but I'm not having any luck.
function postToFacebook(item_id)
{
FB.api(
'/me/completeset:display',
'post',
{ item: 'http://completeset.us/item/'+item_id },
function(response) {
if (!response || response.error) {
alert('Error occured');
} else {
alert('Share was successful! Action ID: ' + response.id);
}
}); //End api
}
I've got the app set up, with an "item" object and the "defined" action defined. I haven't been able to submit the action yet though, because I haven't been able to post anything with it yet. I've verified that the item_id is being passed in correctly, and I've debugged the url using their debugging tool. When I call this function I'm getting unknown path components/ completeset:display. I haven't been able to find much information on this error, so I'm wondering: what are the causes, and how might I be able to fix it?
The names mismatched. The getCode link for the action on facebook displayed the name of the action as being show_off for some reason. It was the same problem as the linked question. I experimented with the app backend and found that if you create an action with one name and then change the name of it, it will display with the new name but you must still reference it using the old name in the code.
My capstone team has decided to use Qooxdoo as the front end for our project. We're developing apps for OpenFlow controllers using NOX, so we're using the NOX webservices framework. I'm having trouble getting data from the service; I know the service is running because if I go to the URL using Firefox the right data shows up. Here's the relevant portion of my code:
var req = new qx.io.remote.Request("http://localhost/ws.v1/hello/world",
"GET", "text/plain");
req.addListener("complete", function(e) {
this.debug(e.getContent());
});
var get = new qx.ui.form.Button("get");
get.addListener("execute", function() {
alert("The button has been pressed");
req.send();
}, this);
form.addButton(get);
In the firebug console I get this message after I click through the alert:
008402 qx.io.remote.Exchange: Unknown status code: 0 (4)
And if I press the Get button again I get this error:
027033 qx.io.remote.transport.XmlHttp[56]: Failed with exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: file:///home/user/qooxdoo-1.0-sdk/framework/source/class/qx/io/remote/transport/XmlHttp.js :: anonymous :: line 279" data: no]
I've also looked at the Twitter Client tutorial, however the "dataChange" event I set up in place of the "tweetsChanged" event never fired. Any help is appreciated, thank you.
This sound like a cross domain request issue. qx.io.remote.Request uses XHR for transporting the data which may not work in every case due to the browser restriction. Switching the crossDomain flag on the request to true will change from XHR to a dynamically inserted script tag doesn't have the cross domain restriction (but other restrictions).
req.setCrossDomain(true);
Maybe that solves your problem.
Additionally, you can take a look at the documentation of the remote package to get some further details on cross domain requests:
http://demo.qooxdoo.org/current/apiviewer/#qx.io.remote
Also take care not to use a request object twice. The only work once.