Cross Domain Support for Aerogear.js
by Lucas Holmquist
can also be seen here https://gist.github.com/4227377
This gist relates to AEROGEAR-534, https://issues.jboss.org/browse/AEROGEAR-534
I created a node.js server that handles CORS and jsonp for my testing
Cross Domain Support
To do cross domain request, i've modified aerogear.js a bit.
I've added a new settings variable, settings.crossdomain, that can be mixed. If set to true, it will default to CORS, to override to jsonp set settings.crossdomain.type = "jsonp"
var pipeline = AeroGear.Pipeline();
jsonp = pipeline.add( {
name: "jsonp",
settings: {
baseURL: "http://localhost:8080",
endpoint: "/",
crossdomain: {
type: "jsonp",
jsonp: "jsonp" //this is optional and will default to callback, jquery default
}
}
});
cors = pipeline.add( {
name: "cors",
settings: {
baseURL: "http://localhost:8080",
endpoint: "/",
crossdomain: true
}
});
If the user wants to use CORS, settings.crossdomain = true, but there browser doesn't support CORS, then AeroGear.Ajax will fallback to jsonp
CORS
since IE9 doesn't use the same thing as the rest of the browser world, i add in a small lib,https://github.com/jaubourg/ajaxHooks, in the external/ actually just the xdr.js file
Although i haven't actually tested that it works
AeroGear.Ajax
The majority of the changes happen in the AeroGear.Ajax function
Here is the commit for this
https://github.com/lholmquist/aerogear-js/commit/d3d3ecaac1d2648f37d66b46...
At the moment the only overridable options in the crossdomain object are jsonp related. I guess this would be the place to add CORS options, if we wanted to
Interestingly enough, if you don't specify any of the new settings, CORS will work, if the server supports it, out of the box.
This is my simple node.js server
var express = require( "express" );
var app = express();
app.all( "/", function(request,response) {
// When dealing with CORS (Cross-Origin Resource Sharing)
// requests, the client should pass-through its origin (the
// requesting domain). We should either echo that or use *
// if the origin was not passed.
var origin = (request.headers.origin || "*");
// Check to see if this is a security check by the browser to
// test the availability of the API for the client. If the
// method is OPTIONS, the browser is check to see to see what
// HTTP methods (and properties) have been granted to the
// client.
if (request.method.toUpperCase() === "OPTIONS"){
// Echo back the Origin (calling domain) so that the
// client is granted access to make subsequent requests
// to the API.
response.status( 204 );
response.header(
{
"access-control-allow-origin": origin,
"access-control-allow-methods": "GET, PUT, DELETE, OPTIONS",
"access-control-allow-headers": "content-type, accept",
"access-control-max-age": 10, // Seconds.
"content-length": 0
}
);
}
// End the response - we're not sending back any content.
response.status( 200 );
response.header(
{
"access-control-allow-origin": origin,
"content-type": "application/json"
}
);
var callback = request.query.callback || request.query.jsonp;
if( callback ) {
response.send( callback + "({response:'stuff'})");
} else {
response.send( {response:'stuff'});
}
});
app.listen( 8080 );
// Debugging:
console.log( "Node.js listening on port 8080" );
12 years, 10 months
AEROGEAR-574 - pull request
by Sebastien Blanc
Hi,
I've submitted a pull request[1] for Jira 574[2].
Basically, I have created a new kitchensink quickstart app containing the
Aerogear JS libraries where I make use of :
* Pipes
* DataStore Manager
Comments and questions are welcome.
I have also locally a version that includes the Aerogear Controller but I
decided to not include it for the moment as I think it's better that we
wait that AG controller supports restful endpoints and include a html view
resolver.
I also attempt to include the aerogear library in the helloworld quickstart
app but I came on the conclusion that this didn't make really sense for now
as the use case is to trivial and do not fit with the behavior of a AG pipe
: The current HelloWorld currently just send a POST request passing a
String in the path (and not through data payload).
We could change this by refactoring the app but I'm afraid we will end
up with something very similar to the kitchensink app and this will be a
bit redundant.
Regards,
Seb
[1]https://github.com/aerogear/as-quickstarts/pull/52
[2]https://issues.jboss.org/browse/AEROGEAR-574
12 years, 10 months
Scaffolding / Rapid Development Tools
by Sebastien Blanc
Hi,
We are currently brainstorming on the different ways that can speed up
the development time of a project using Aerogear.
Speeding up the development include several concepts :
* Setting up the project structure.
* Scaffolding the Backend logic based on user inputs.
* Scaffolding the CRUD views based on your domain model / user inputs.
* Boost the test/integration/deployment process
What do you we currently have ?
In the Java/JEE corner :
Well, Maven offers already some kind of project structure if you follow its
conventions.
Regarding scaffolding we have a tool called "forge" in which you can plug
in "quite" easily extensions to customize the scaffolding.
In the JS corner :
We have tools like Grunt andYeoman which will be able to handle the front
end stuff
What is the targeted audience ?
That's one of the first challenges :
* We have JEE/Java
* We have JS developpers
* We have mobile native developpers
And of course, most of the time we will have a mix of these 3 profiles ...
For example, JS devs won't be very excited if they have only maven/forge as
options to boost up the development time. On the contrary, Java/JEE devs
would like to stick to existing tools that fits well in their development
process ...
We could propose a tool for each profile or find a way in the middle, but I
would love to hear your thoughts, ideas, remarks.
Regards,
Seb
12 years, 10 months
