Try to run it from a published app.
Create a new screen.
Define the service as explained in the preceeding screenshots and add it to the screen. Make one Javascript for OnSuccess and one for Error each with a meaningful message.
Invoke the service via a standard button.
Test it with the Test button, and verify that it displays your message:
Now close the project, and use the one click publish method. In your favorite browser, enter the url of your hosted app. Try to click the button now:
Correct, for some reason the proxy is not used at all. So you get the standard cross domain error. We will fix it.
Thank god. This explains everything. Please let me now when you have some more info about this issue.
Ole
As a possible workaround, are you able to update your services to support cross-domain calls?
This was my idea last month. And this worked so well with GET calls and CORS support on the server.
Then I started to read about correct use of REST, and that I should use POST when I needed to update data. CORS on the server makes GET function very well. But other commands like POST seems not to work in this scenario. Its a Datasnap REST server from Embarcadero.
Hi!
Just wondering.
Is this issue solved?
best regards
Ole H. Oftedal
Timeflex Systemer AS
http://www.timeflex.com
http://www.timeflex.no
Apologies for the delay.
Here is what's happening. We are going to re-introduce this feature as part of our Backend Services with a layer of security. The security feature will enable you to hide any API keys that are now visible in the browser.
The current proxy is very useful during development but it is simply not tuned for production. A simple workaround today would be to enable cross-domain class in the service you are using. Another option is to host the HTML5 mobile app on the same domain as the service.
Hi again!
What will be the time estimate here?
Because right now I haven't got a work around.
1:enable cross-domain class in the service
This I think is only supported on GET calls. When I use POST the service fails. My test POST service works now from both an Android App and also via the Tiggzi proxy. But not from a Web server with CORS enabled. (confirmed by third parti that it was a valid cross-origin server (enable-cors.org))
2:option is to host the HTML5 mobile app on the same domain as the service.
I don't think this is supported in my scenario. Everything must be identical for this to work. Not just the domain, but also server and port number. I think it compares the server part of the url. Not just the domain name. This is also logical or else this could be a great security issue for the Cloud. I.e. Microsoft has all servers on the same domain (cloudapp.net) and thousands of different customers running with the same domain name.
Ole.
[quote:]
1:enable cross-domain class in the service
This is think is only supported on GET calls. When I use POST the service fail. The same service work both as a Android App and also via the Tiggzi proxy. I have tested this in twice in two scenarios and last one confirmed by third parti that it was a valid cross-origin server (enable-cors.org)
[/quote]
You can enable cross-domain class for any request, including POST. Tiggzi database supports cross-domain calls for all types of requests.
The service works on Android or in the tester because cross-domain security doesn't play a role. It's only when making a request from a page.
Yes. But there could be a bug in the exported CSS/HTML code or somewhere else.
Here how to reproduce.
A)
Let someone make a super simple service. I have already made one here:
ofto3.cloudapp.net:8082/datasnap/rest/TServerMethods1/echoAttribute/Attr1
(A demo function in the Delphi Datasnap product see http://docwiki.embarcadero.com/RADStu... )
The purpose of this service is to return the textstring in the JSON key "Attr1". The JSON object must be sent in the body of the REST call (not in the url).
B)
Use Your favorite HTTP send test tool and enter data
Method: Post
{"Attr1":"Hello World"}
Verify that you get this in return
{"result":["Hello World"]}
And also check for * in access-control-allow-origin
C)
Now make one of the Worlds simplest Tiggzi apps. Add one service.
One input and one text. The button invokes the service. Make an Alert Message if the service fails so you can easily see what happens.
With Tiggzi proxy on everything works perfect. Now do not include Tiggzi proxy on the service by removing the checkmark. (When you test without proxy the service fails for Mozilla firefox and safari. IE is more relaxed to cross-origin problems and it in fact works fine here.)
The service:
D)
Make your own Internet Information server 7. Enable Cors on that server. See http://enable-cors.org. Verify that this site acknowledge this to be a cors (cross-origin) server. Can be done at the same page. Put you exported files on your new web server. (CORS setup on the server handling the REST service is already enabled.)
E)
Now suddenly all browser types report an error when run from the new server. Even IE.
Firebug says: "NetworkError: 500 Internal Server Error - http://ofto3.cloudapp.net:8082/datasn...". When using GET instead of POST everything works fine.
Ole.
Part of the generated exported js code :
var RESTService = new Tiggr.RestService({
'url': 'http://ofto3.cloudapp.net:8082/datasn...',
'dataType': 'json',
'type': 'post',
'contentType': 'application/json',
});
...
/*************************
* NONVISUAL COMPONENTS *
**********************/
var datasources = [];
restservice2 = new Tiggr.DataSource(RESTService, {
'onComplete': function(jqXHR, textStatus) {
$t.refreshScreenFormElements("j_0");
},
'onSuccess': function(data) {},
'onError': function(jqXHR, textStatus, errorThrown) {
alert("service failed");
},
'responseMapping': [{
'PATH': ['result[0]'],
'ID': 'mobilelabel19',
'ATTR': '@'
}],
'requestMapping': [{
'PATH': ['Attr1'],
'ID': 'mobiletextinput18',
'ATTR': 'value'
}]
});
datasources.push(restservice2);
/*********************