mirror of https://gitee.com/bigwinds/arangodb
136 lines
4.7 KiB
Plaintext
136 lines
4.7 KiB
Plaintext
!CHAPTER Handling Requests
|
|
|
|
In development mode all available applications from the application directory
|
|
*/home/user/apps/databases/<database name>/* are visible under
|
|
*http:// localhost:8529/dev/<directory name>* where *<database name>* is the
|
|
name of the current database and *<directory name>* is the directory name of your
|
|
application.
|
|
|
|
In our example, *<directory name>* was *my_app* and as we didn't specify a
|
|
database, *<database name>* defaulted to *_system*.
|
|
|
|
When applications are installed in production mode, you can change the */dev*
|
|
prefix to whatever you like, see [Foxx Manager](../FoxxManager/README.md).
|
|
|
|
If you do not redefine it, all requests that go to the root of your
|
|
application (i.e. */*) will be redirected to *index.html*.
|
|
|
|
This means that if your application does not provide a file *index.html*,
|
|
calling the application root URL may result in a 404 error.
|
|
In our example, the application root URL is *http://localhost:8529/dev/my_app/hello/*.
|
|
Call it, and you should something like this in return:
|
|
|
|
```
|
|
{
|
|
"error": true,
|
|
"code": 404,
|
|
"errorNum": 404,
|
|
"errorMessage": "unknown path 'dev/my_app/index.html'"
|
|
}
|
|
```
|
|
|
|
To fix that, you can give your app a different default document, e.g. "hello/unknown".
|
|
The adjusted manifest now looks like this:
|
|
|
|
```
|
|
{
|
|
"name": "my_app",
|
|
"version": "0.0.1",
|
|
"author": "me and myself",
|
|
"controllers": {
|
|
"/": "app.js"
|
|
},
|
|
"defaultDocument": "hello/unknown"
|
|
}
|
|
```
|
|
|
|
**Note**: Browsers tend to cache results of redirections. To see the new default
|
|
document in effect, first clear your browser's cache and point your browser
|
|
to *http:// localhost:8529/dev/my_app/*.
|
|
|
|
!SUBSECTION Accessing collections from Foxx
|
|
|
|
|
|
Foxx assumes by default that an application has it's own collections.
|
|
Accessing collections directly by name could cause problems, for
|
|
instance if you had two completely independent Foxx applications that
|
|
both access their own collection *'users'*.
|
|
|
|
To prevent such issues, Foxx provides functions that return an
|
|
application-specific [collection name](../Glossary/README.html#collection_name).
|
|
For example, *applicationContext.collectionName('users')* will return the
|
|
collection name prefixed with the application name, e.g. "myapp_users".
|
|
This allows to have a *users* collection which is specific for each
|
|
application.
|
|
|
|
Additionally, a Foxx controller has a function "collection" that returns
|
|
a reference to a collection prefixed like above, in the same way as
|
|
*db.<collection-name>* would do.
|
|
In the example, controller.collection('users') would return the
|
|
collection object for the "myapp_users" collection, and you could use it
|
|
like any other collection with the db object, e.g.
|
|
|
|
```
|
|
controller.collection('users').toArray()
|
|
controller.collection('users').save(...)
|
|
controller.collection('users').remove(...)
|
|
controller.collection('users').replace(...)
|
|
```
|
|
|
|
Of course you still use any collection directly with the db object even
|
|
from Foxx. To access an collection called "movies" this could be one solution:
|
|
|
|
```js
|
|
app.get("/all", function(req, res) {
|
|
var db = require("org/arangodb").db;
|
|
res.json({ movies: db.movies.toArray() });
|
|
});
|
|
```
|
|
|
|
Of course this completely bypasses prefixing and repositories, but works
|
|
well especially for quick tests or shared collections that are NOT
|
|
application-specific.
|
|
|
|
Then there are Foxx repositories. These are objects that you can create
|
|
to hide the internals of the database access from the application so
|
|
that the application will just use the repository but not the database.
|
|
|
|
A repository is an object that wrap access to a collection (or multiple
|
|
collections if you want), whereas controller.collection returns the
|
|
collection itself. That's the main difference.
|
|
|
|
To return a list of users from a controller using a repository, you
|
|
could use it like this:
|
|
|
|
```js
|
|
var foxx = require("org/arangodb/foxx");
|
|
var db = require("org/arangodb").db;
|
|
var usersRepo = new foxx.Repository(db._collection("users"));
|
|
app.get("/all", function(req, res) {
|
|
res.json({ users: usersRepo.collection.toArray() });
|
|
});
|
|
```
|
|
|
|
Of course you can create your own methods in the repository to add extra
|
|
functionality.
|
|
|
|
!SUBSECTION Application Context
|
|
|
|
JavaScript modules within a Foxx application can access the application using
|
|
the variable *applicationContext*. The applicationContext provides the following
|
|
methods:
|
|
|
|
`applicationContext.collectionName(name)`
|
|
|
|
This returns the collection name with the application.
|
|
|
|
`applicationContext.foxxFilename(filename)`
|
|
|
|
This returns the path to a file within the Foxx directory.
|
|
|
|
`require(name)`
|
|
|
|
This will first look into the Foxx directory for a module
|
|
named *name*. If no such module can be found, the global module paths
|
|
are consulted.
|