Djang10 is a model-view-controller (MVC) framework inspired by Python's Django, implemented in JavaScript for the 10gen platform. Djang10 is similar to its namesake, with important differences.
Setup
Set up your site’s root as the Djang10 project root. To do so, place the following files in your site’s root:
_init.jsinitializes the Djang10 framework by callingcore.Djang10.install();The install routine:- parses
urls.jsand installs your defined routes into the global routes object - initializes the database collections for your models
- isolates the scopes of your 'installed' Djang10 applications (see below)
settings.jsis equivalent to Django’ssettings.py. It contains the configuration variables needed to set up your Djang10 environment.urls.jsmaps URLs to handler methods in the views. A view is equivalent to a controller in other MVC frameworks.
Applications
A Djang10 project can contain any number of Djang10 applications. Each application is a subdirectory of the project and contains the following files:_init_.jxp  marks it as a Djang10 application. It is just a marker - it has no functional value and its contents are ignoredmodels.js  contains all the persistent domain objectsviews.js  contains your views
Templates
Djang10 templates are almost identical to the Django templates, with minor differences. They are parsed into nodes on first access and remain cached in memory until the source is modified.Additional functionality:
- methods can be called w. parameters:
- {{ myvar.myMethod("aString", aVarInTheContext) }}
- {% for aVar in aVar.getSomeArray("paramStr1") %}
- array index notation:
- {{ anArray[3] }}
- array literal notation is supported:
- {% for aVar in [1,4,5] %}
- variable lookups fallback on the global scope when they aren't found in the context (configurable)
- absolute paths are supported for extending and including templates
- absolute paths fallback to being resolved as relative paths against the site
- filter syntax is a lot more forgiving and allows for whitespace
- {{ aVar | upper }}
- string escaping is processed: {{ "foo\tbar" }} prints "foo bar" instead of "foo\tbar" (configurable)
- Configuration is done by manipulating the global djang10 object
- djang10.ALLOW_GLOBAL_FALLBACK: (true/false) controls if variable lookups fallback on the global scope if they aren't found in the Context
- djang10.TEMPLATE_DIRS: an array of Strings or FileLibraries that are used as a search path for locating templates.
- ie. djang10.TEMPLATE_DIRS.push("/local/templates")
- ie. djang10.TEMPLATE_DIRS.push(local.templates)
- djang10.TEMPLATE_LOADERS: an array of loaders, that will be called in reverse order to resolve template names
- each loader is called with a template name, and is expected to either return a djang10 Template or null
- a loader can be specified as either a function or a string that specifies the function and the file its in.
- ie. djang10.TEMPLATE_LOADERS.push(function(templateName) { return local[templateName];})
- ie. djang10.TEMPLATE_LOADERS.push("path.to.file.theLoaderFunction");
- djang10.TEMPLATE_STRING_IF_INVALID: the string to use when a variable value is undefined. If you include a %s in the string, it will replaced with expression.
- djang10.TEMPLATE_STRING_IF_INVALID = "Not found"; {{ null.prop }} => Not found
- djang10.TEMPLATE_STRING_IF_INVALID = "Undefined expression: %s"; {{ null.prop }} => Undefined expression: null.prop
- to add a template root: add an entry to the djang10.TEMPLATE_DIRS array
- to add a template tag library: add an entry to the djang10.TEMPLATE_LOADERS array
- helper objects also live in the djang10 global object:
- djang10.Context
- djang10.Library
- djang10.Node
- djang10.Expression replaces django.template.Variable
- djang10.mark_safe() and djang10.is_safe() functions replace the SafeData object
- djang10.NewTemplateException() function replaces the django TemplateSyntaxError expection object
- djang10.get_template() function replaces the django.template.loader.get_template()
Writing your own Tags & Filters:
Is very similar to django:The main difference is javascript style of inheritance and the introduction of a more optimized render method. Although the django way of rendering still works, it is recommended to use the new __render method. in most cases it will allow your template to be streamed out to the browser while its being rendered.
//global register variable
register = new djang10.Library();
//create a new filter
function append(value, arg) {
return value + arg;
}
//register it
register.filter("append", append);
//create a Node
function HideOddChildren(nodelist) {
this.nodelist = nodelist;
}
HideOddChildren.prototype = {
//extend Node
__proto__: djang10.Node.prototype,
//override the optimized rendering behavior
__render: function(context, printer) {
for(var i=0; i%lt;this.nodelist.length; i++) {
this.nodelist.__render(context, printer);
}
}
};
//create the tag handler
function hideOddChildren(parser, token) {
var nodelist = parse.parse(["endhide_odd_children"]);
parser.delete_next_token();
return new HideOddChildren(nodelist);
}
//register it
register.tag("hide_odd_children");
Limitations:
- most filters have been implemented, the only filters not implemented are:
- cache
- urlize
- unicode is not supported
- translation is not implemented
- you can enable debugging output via log.djang10.*.level
- Categories:
- djang10.loader -> detailed error messages of template loading failing
- djang10.loaders -> detailed step by step reasons what loaders were invoked and why they failed/succeeded
- djang10.loaders.filesystem
- djang10.loaders.absolute
- djang10.loaders.site_relative
- djang10.Djang10Source -> logs messages of when a template is parsed
- djang10.expression -> logs messages of expression evaluation
- djang10.NodeWrapper -> verbose logging of node rendering tree
- ie:
- log.djang10.level = log.LEVEL.DEBUG; //enable all the logging
- log.djang10.loader = log.LEVEL.DEBUG; //enable loader messages
