Instructions can be found here : http://forge.jboss.org/docs/using/
AG Controller scaffolding needs some features only available in a branch : Clone this repo :
https://github.com/sebastienblanc/aerogear-controller
and check out this branch :
apiVersion: console.openshift.io/v1 | |
kind: ConsoleQuickStart | |
metadata: | |
name: serverless-cli | |
spec: | |
displayName: Serverless CLI | |
description: todo | |
durationMinutes: 10 | |
tags: | |
- knative |
node1: | |
image: hauptmedia/mariadb:10.1 | |
hostname: node1 | |
ports: | |
- 13306:3306 | |
environment: | |
- MYSQL_ROOT_PASSWORD=unifiedpush | |
- REPLICATION_PASSWORD=unifiedpush | |
- MYSQL_DATABASE=unifiedpush | |
- MYSQL_USER=unifiedpush |
var leaguePipe = AeroGear.Pipeline(); | |
pipeline.add( "leagues", { | |
baseURL: "http://soccer.org/", | |
}).leagues; | |
//READ "teams" for league "seattle": | |
// http://soccer.org/leagues/seattle/teams | |
leaguePipe.read({ | |
id: "seattle", | |
resource: "/teams", |
Instructions can be found here : http://forge.jboss.org/docs/using/
AG Controller scaffolding needs some features only available in a branch : Clone this repo :
https://github.com/sebastienblanc/aerogear-controller
and check out this branch :
This document is intended to describe AeroGear Controllers integration with RestEasy.
Currently, the routes that AeroGear Controller can handle are "one way" in the sense that they go through AeroGear Controller are forwarded to a view, which can be populated by a data model provided by the Controller for the route in question.
For example:
route()
.from("/customers/{id}")
.on(RequestMethod.GET)
class Pipeline { | |
PipeBuilder add() { | |
return new PipeBuilder(this); | |
} | |
} | |
class Pipebuilder { | |
PipeBuilder withUrl(..) | |
.... | |
.... |
A pipeline represents a set of n connections to a server. The pipeline class offers some simple 'management' APIs to work with containing 'pipe' objects. Basically it allows you to add or remove new connections to the pipeline.
A pipe represents one connection to a server. The pipe API is basically an abstraction layer for any server side connection, which all allows you to simply 'read' from, or 'write' to a server connection. However, technical details like RESTful APIs (e.g. HTTP PUT or HTTT GET) are not exposed on the pipeline and pipe APIs. In the future you can have different type of pipe objects (-> connections). The default (and CURRENTLY only supported) type is a REST connection.
Below is an example from our JavaScript lib:
A pipeline represents a set of n connections to a server. The pipeline class offers some simple 'management' APIs to work with containing 'pipe' objects. Basically it allows you to add or remove new connections to the pipeline.
A pipe represents one connection to a server. The pipe API is basically an abstraction layer for any server side connection, which all allows you to simply 'read' from, or 'write' to a server connection. However, technical details like RESTful APIs (e.g. HTTP PUT or HTTT GET) are not exposed on the pipeline and pipe APIs. In the future you can have different type of pipe objects (-> connections). The default (and CURRENTLY only supported) type is a REST connection.
Below is an example from our JavaScript lib:
/* | |
* SenTestingKit does not wait for blocks to finish by default so your test would simply complete | |
* as successful. You need to use a semaphore and keep the run loop going in order for the test | |
* to properly run. | |
*/ | |
- (void)testGetSpots { | |
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); | |
CLLocation location = [[CLLocation alloc] initWithLatitude:70.0 longitude:50.0]; | |
[Spot spotsWithURLString:@"/spots" near:location parameters:[NSDictionary dictionaryWithObject:@"128" forKey:@"per_page"] block:^(NSArray *records) { | |
//sample assert |