Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(292)

Side by Side Diff: examples/js/README.md

Issue 776133003: Mojo JS Bindings User's Guide (Closed) Base URL: https://github.com/domokit/mojo.git@master
Patch Set: Created 6 years ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
1 JavaScript Mojo Example Applications 1 JavaScript Mojo Example Applications
2 ===================== 2 =====================
3 3
4 hello.js, world.js - A minimal application that connects to another. 4 hello.js, world.js - A minimal application that connects to another.
5 5
6 wget.js - Uses the network service to load a URL. 6 wget.js - Uses the network service to load a URL.
7 7
8
9 --- Running Mojo Applications ---
10
11 A Mojo application written in JavaScript is launched with mojo_shell like this:
12
13 mojo_shell <js-application-url>
14
15 Where js-application-url is either a file or an http URL that names a JS source
16 file. The JS file itself must begin with a Mojo "shebang" that specifies the
17 Mojo URL of the JS content handler. In other words, the first line of the JS
18 source file must be:
19
20 #!mojo:js_content_handler
21
22 Following the shebang should be a single AMD module called "main" whose value
23 is an Application class. The JS content handler will create an instance of the
24 Application and make it the client of the Mojo shell. The JS content handler is
25 itself a Mojo application and it's responsible for creating an instance of V8
26 and loading the "main" JS module and all of the modules the main module
27 depends on.
28
29 The overall structure of a JS Mojo application is this:
30
31 #!mojo:js_content_handler
32
33 define("main", [<list of modules this application depends on>],
34 function(<one parameter per dependent module>) {
35 function Application(appShell, url) {
36 }
37
38 Application.prototype.initialize = function(args) {
39 }
40
41 Application.prototype.acceptConnection = function(url, spHandle) {
42 }
43
44 return Application;
45 });
46
47 The hello.js example is little more than this basic skeleton.
48
49 The JS content handler loads the "main" module and makes an instance of its
50 value, which must be the application's class. The application's constructor is
51 passed two arguments:
52
53 appShell - a pointer to the Mojo shell. Typically this will be wrapped by a
54 Shell object, see below.
55
56 url - the URL this application was loaded from as a String.
57
58 The initialize() and acceptConnection() methods are defined by application.mojom
59 and they're needed because the JS content handler makes the JS application the
60 Mojo shell's client.
61
62
63 --- Mojo Application Structure ---
64
65 Mojo applications can connect to services provided by other applications and
66 they can provide services of their own. A service is an implementation of a Mojo
67 interface that was defined as part of a Mojo module in a ".mojom" file.
68
69 To implement a service you'll need the JS "bindings" for the Mojo interface. The
70 bindings are generated by the build system and end up in files whose name is the
71 same as the '.mojom' file with a '.js' suffix. It's often helpful to look at the
72 generated 'mojom.js' files.
73
74 The JS Shell class simplifies connecting to applications and services. It's a
75 wrapper for the Application's appShell argument.
76
77 The Shell's connectToService() method returns a "proxy" to a service provided by
78 another application.
79
80 The JS bindings for a Mojo interface's API are delivered as a JS module whose
81 name is based on the '.mojom' file's path. For example, to use the Mojo network
82 service you need the JS module based on network_service.mojom:
83
84 define("main", [
85 "mojo/services/public/interfaces/network/network_service.mojom",
86 "mojo/services/public/js/shell",
87 ]
88 function(netModule, shellModule) {
89 function Application(appShell, url) {
90 this.shell = new shellModule.Shell(appShell);
91 }
92
93 Application.prototype.initialize = function(args) {
94 var netService = this.shell.connectToService(
95 "mojo:network_service", netModule.NetworkService);
96
97 }
98 ...
99 return Application;
100 });
101
102 The first connectToService() parameter is the Mojo URL for the network service
103 application and the second is the JS "interface" object for NetworkService. The
104 JS interface object's properties identify the (generated) JS bindings classes
105 used to provide or connect to a service. For example (from
106 network_service.mojom.js):
107
108 var NetworkService = {
109 name: 'mojo::NetworkService', // Fully qualified Mojo interface name.
110 proxyClass: NetworkServiceProxy,
111 stubClass: NetworkServiceStub,
112 // ...
113 };
114
115 The 'proxyClass' is used to access another application's NetworkService and the
116 'stubClass' is used to create an implementation of NetworkService.
117
118 In the netService case above the Shell connects to the Mojo application at
119 "mojo:network_service", then connects its service called
120 'NetworkService.name' with an instance of 'NetworkService.proxyClass'. The proxy
121 instance is returned.
122
123
124 --- Interface Parameters ---
125
126 Mojo functions with interface valued parameters allow one to request a service
127 from a service or to provide a service to a service. The
128 indirect_service example demonstrates this.
129
130 The NetworkService CreateURLLoader() method has an interface request parameter:
131
132 interface NetworkService {
133 CreateURLLoader(URLLoader& loader); // Return a URLLoader to the caller.
134 ...
135 }
136
137 Interface request parameters can be specified as an instance of the interface's
138 proxy class. Ordinary interface parameters can be specified as an instance of
139 the interface's stub class. The stub class constructor has an optional delegate
140 parameter that defines the stub's implementation.
141
142 Here's an example of an interface request parameter taken from wget.js:
143
144 var urlLoader = new loader.URLLoader.proxyClass;
145 netService.createURLLoader(urlLoader); // interface& parameter
146
147 var urlRequest = new loader.URLRequest({
148 url: "http://www.cnn.com",
149 method: "GET",
150 auto_follow_redirects: true
151 });
152
153 urlLoader.start(urlRequest).then(function(result) {
154 // ..Do something with result.response
155 });
156
157
158 --- Mojo Responses are Promises ---
159
160 Mojo functions can return zero or more values called a "response". For example
161 the EchoString function below returns a string or null.
162
163 interface EchoService {
164 EchoString(string? value) => (string? value);
165 };
166
167 The response is delivered to the function caller asynchronously. In C++ the
168 caller provides a Callback object whose Run() method has one argument for
169 each response parameter. In JS, Mojo functions that specify a response return
170 a Promise object. The Promise resolves to an object with one property per
171 response parameter. In the EchoString case that would be something like
172 {value: "foo"}.
173
174 Similarly, the implementation of a Mojo interface functions that specify a
175 response, must return a Promise. The implementation of EchoString() could
176 be written like this:
177
178 MyEchoStringImpl.prototype.EchoString = function(s) {
179 return Promise.resolve({value: s});
180 };
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698