initialization
When an application starts up, the first that happens is that the system determines the code to be used and which database to connect to.When running locally:
- the application server just uses the code that is currently checked out.
- the database to be used is the name of the directory the code is in
- the database server connected to is found by looking through command line arguments, config files and then falls back to localhost
- the application server will make sure that it has the correct git tag or branch checked out and is up to date
- it will use the configured database for the environment it is in.
_config.js
Once basic initalization is done, _config.js is loaded if it exists. No real code should go in a _config.js It is meant for controlling which versions of libraries to use. For example, we will continuouly release changes of the wiki core-module. By default, your code will use the tag that we've marked stable But lets say for whatever reason you want to use a certain version, you could do this:version = {
wiki : "r0.1.5"
}
or
version = {
wiki : "stage"
}
_init.js
After _config.js is called the application server finishes the low level setup, like installing the right version of corejs and the admin module. Finally, your code is ready to be called.The first thing that happens is /_init.js _init.js is where you can load libraries and models, setup routes, define globale variables and functions, and setup some key functions. It is usually called once when the application start. _init.js, however, does do dependency tracking. So if you are running locally, and either modify _init.js, or a file included from _init.js (through any depth), it will cause _init.js to get re-run. This means that when you are developing, you should never have to restart your application server to re-load code changes. Everything in 10gen is designed so that you should rarely have to actually restart the application.
There are few key magic functions that you can define in _init.js
- allowed
- if this is defined, it is invoked before every request is processed.
- it can be used to do authentication, or even log every request
allowed = function( request , response , uri ){
log.access.log( uri );
if ( ! request.getCookie( "good" ) ){
return "bad";
}
}
- If allowed returns anything besides null, the request is rejected
- mapUrlToJxpFile
- while the reccomended way of doing routing in your application is using routes you can also do it with this low level method
- mapUrlToJxpFile can re-route any request to any file you wish
- map everything to a single place
mapUrlToJxpFile = function( uri , request , response ){
return "/catchall.jxp";
}
- maybe you want to do some SEO url optimization
mapUrlToJxpFile = function( uri , request , response ){
if ( uri.match( /^.-/ ) ){
request.query = uri.substring( 3 );
return "/list.jxp";
}
}
- if you send a response code >300 (using response.sendError() or response.sendRedirect() for example) the response will be sent ignoring the result of mapUrlToJxpFile
response.addDoneHook()
Another interesting lifecycle thing (though technically request lifecycle, not application) is response.addDoneHook In your application you may create some temporary data in the database, or have some cleaning to do after a request is finished. You can call response.addDoneHook() with a function, and that will be invoked when the request is done being sent.Note: in this case, done being sent refers to being written out. It does not guarantee the user has downloaded the entire response, just the the application server is done processing it.
response.addDoneHook(
function(){
db.tempObject.remove( { key : mykey } );
}
);