mirror of https://gitee.com/bigwinds/arangodb
136 lines
4.9 KiB
Plaintext
136 lines
4.9 KiB
Plaintext
!CHAPTER The Manifest File
|
|
|
|
In the *manifest.json* you define the components of your application.
|
|
The content is a JSON object with the following attributes (not all
|
|
attributes are required though):
|
|
|
|
* *assets*: Deliver pre-processed files
|
|
* *author*: The author name
|
|
* *contributors*: An array containing objects, each represents a contributor (with *name* and optional *email*)
|
|
* *controllers*: Map routes to FoxxControllers
|
|
* *defaultDocument*: The default document when the applicated root (*/*) is called (defaults to *index.html*)
|
|
* *description*: A short description of the application (Meta information)
|
|
* *engines*: Should be an object with *arangodb* set to the ArangoDB version your Foxx app is compatible with.
|
|
* *files*: Deliver files
|
|
* *isSystem*: Mark an application as a system application
|
|
* *keywords*: An array of keywords to help people find your Foxx app
|
|
* *lib*: Base path for all required modules
|
|
* *license*: Short form of the license (MIT, GPL...)
|
|
* *name*: Name of the application (Meta information)
|
|
* *repository*: An object with information about where you can find the repository: *type* and *url*
|
|
* *setup*: Path to a setup script
|
|
* *teardown*: Path to a teardown script
|
|
* *thumbnail*: Path to a thumbnail that represents the application (Meta information)
|
|
* *version*: Current version of the application (Meta information)
|
|
|
|
If you install an application using the Foxx manager or are using the
|
|
development mode, your manifest will be checked for completeness and common errors.
|
|
You should have a look at the server log files after changing a manifest file to
|
|
get informed about potential errors in the manifest.
|
|
|
|
A more complete example for a Manifest file:
|
|
|
|
{
|
|
"name": "my_website",
|
|
"version": "1.2.1",
|
|
"description": "My Website with a blog and a shop",
|
|
"thumnail": "images/website-logo.png",
|
|
|
|
"controllers": {
|
|
"/blog": "apps/blog.js",
|
|
"/shop": "apps/shop.js"
|
|
},
|
|
|
|
"lib": "lib",
|
|
|
|
"files": {
|
|
"/images": "images"
|
|
},
|
|
|
|
"assets": {
|
|
"application.js": {
|
|
"files": [
|
|
"vendor/jquery.js",
|
|
"assets/javascripts/*"
|
|
]
|
|
}
|
|
},
|
|
|
|
"setup": "scripts/setup.js",
|
|
"teardown": "scripts/teardown.js"
|
|
}
|
|
|
|
!SUBSECTION The setup and teardown scripts
|
|
|
|
You can provide a path to a JavaScript file that prepares ArangoDB for your
|
|
application (or respectively removes it entirely). These scripts have access to
|
|
*appCollection* and *appCollectionName*. Use the *setup* script to create all
|
|
collections your application needs and fill them with initial data if you want
|
|
to. Use the *teardown* script to remove all collections you have created.
|
|
|
|
Note: the setup script is called on each request in the development mode.
|
|
If your application needs to set up specific collections, you should always
|
|
check in the setup script whether they are already there.
|
|
|
|
The teardown script is called when an application is uninstalled. It is good
|
|
practice to drop any collections in the teardown script that the application used
|
|
exclusively, but this is not enforced. Maybe there are reasons to keep application
|
|
data even after removing an application. It's up to you to decide what to do.
|
|
|
|
!SUBSECTION controllers is an object that matches routes to files
|
|
|
|
* The *key* is the route you want to mount at
|
|
|
|
* The *value* is the path to the JavaScript file containing the
|
|
*FoxxController* you want to mount
|
|
|
|
You can add multiple controllers in one manifest this way.
|
|
|
|
!SUBSECTIONThe files
|
|
|
|
Deliver all files in a certain folder without modifying them. You can deliver
|
|
text files as well as binaries:
|
|
|
|
"files": {
|
|
"/images": "images"
|
|
}
|
|
|
|
!SUBSECTION The assets
|
|
|
|
The value for the asset key is an object consisting of paths that are matched
|
|
to the files they are composed of. Let's take the following example:
|
|
|
|
"assets": {
|
|
"application.js": {
|
|
"files": [
|
|
"vendor/jquery.js",
|
|
"assets/javascripts/*"
|
|
]
|
|
}
|
|
}
|
|
|
|
If a request is made to */application.js* (in development mode), the file
|
|
array provided will be processed one element at a time. The elements are
|
|
paths to files (with the option to use wildcards). The files will be
|
|
concatenated and delivered as a single file.
|
|
|
|
The content-type (or mime type) of the HTTP response when requesting
|
|
*application.js* is automatically determined by looking at the filename
|
|
extension in the asset name (*application.js* in the above example).
|
|
If the asset does not have a filename extension, the content-type is
|
|
determined by looking at the filename extension of the first file in the
|
|
*files* list. If no file extension can be determined, the asset will be
|
|
deliverd with a content-type of *text/plain*.
|
|
|
|
It is possible to explicitly override the content-type for an asset by
|
|
setting the optional *contentType* attribute of an asset as follows:
|
|
|
|
"assets": {
|
|
"myincludes": {
|
|
"files": [
|
|
"vendor/jquery.js",
|
|
"assets/javascripts/*"
|
|
],
|
|
"contentType": "text/javascript"
|
|
}
|
|
} |