jeanphix

Nouvelles du Front: Internet Explorer nous retourne le cerveau

2012-03-05T00:00:00-08:00

Depuis quelques temps, je fais de plus en plus de front, ce qui ne me déplaît pas. C’est un domaine très riche où doivent cohabiter: standards, navigateurs et utilisateurs.

C’est sans aucun doute la part de mon métier la plus gourmande en veille et apprentissage. Aussi je me permettrai autour de quelques petits billets de vous faire part, ici même, de mes humeurs et réflexions à ce sujet.

Aujourd’hui, je voudrais vous parler des media queries et des pratiques qui semblent imposées par le retard d’implémentation d’Internet Explorer (les media queries n’y sont interprétées que depuis sa version 9).

Intégrer naturellement

En général quand je commence une feuille de style, elle débute par la mise en place de la typographie: police de caractères, rythme (line-height, margin des hX, ul, p…) ce qui amène généralement un style suffisant et utilisable sur les plus petits devices.

Ensuite, je commence à mettre en place le layout cible en fonction des dimensions du viewport, exemples:

si le viewport est assez grand, je peux faire “flotter” le menu de navigation.
si le viewport est encore plus grand, je peux me permettre un affichage sur trois colonnes
…

En gros : je vais du plus petit au plus grand en incrémentant la feuille de style à l’aide de media queries, qui sont donc du type :

@media screen and (min-width: 800px) {
    ...
}

C’est de loin la façon de faire qui me semble la plus naturelle.

Intégrer en ciblant Internet Explorer

J’ai pu constater en décortiquant certaines intégrations, certaines librairies de style que nombre d’entre nous procèdent à l’inverse: En montant d’abord les styles pour un viewport de dimensions desktop (pour un affichage correct par IE8-) et ensuite en les dégradant pour des viewports plus petits.

Les media queries employées deviennent donc du type :

@media screen and (max-width: 800px) {
    /*
        j'annule des flottants, des fixés...
    */
}

Cela s’appelle tout simplement : “raisonner à l’envers”, et tout ceci, car monsieur Internet Explorer l’impose.

La solution

Elle est pour moi des plus simples : ne pas supporter IE8-.

Sinon, si vraiment vous n’avez pas le choix, il existe une petite librairie javascript sympa et légère qui permet de rendre les media queries supportables par les navigateurs obsolètes: Respond.js.

ps: une autre petite librairie à mettre dans votre boîte à outils: selectivizr.

Django, heroku & S3 FTW

2012-02-08T00:00:00-08:00

Outdated Heroku now automatically runs `collectstatic` on deployment.
By the way, I encourage you to put all your environment specific configs (like database dsn, debug…) into environment variables.

Today I’ll show you my tips backed from a django project deployment over heroku (application) and S3 (statics).

Setting up environments

First of all, I need two remote environments (production and staging) with distinct settings. In order to feet my git workflow, I had to create three local branches:

master: that I push even on heroku `production` application and on a `master` github branch.
staging: that I push even on heroku `staging` application and on a `staging` github branch.
development: that I push on a `development` github branch.

Project bootstrap:

$ pip install django gunicorn psycopg2
$ pip freeze > requirements.txt
$ git init
$ django-admin.py startproject myproject
$ python myproject/manage.py startapp myapp

Then in `myproject/settings.py` I add ‘gunicorn’ to INSTALLED_APPS.

$ echo 'web: python myproject/manage.py run_gunicorn -b "0.0.0.0:$PORT" -w 3' > Procfile
$ git add .
$ git commit -m 'Initial commit'

Production:

$ heroku create --stack cedar --remote production
$ git push production master

Staging:

$ git checkout -b staging
$ heroku create --stack cedar --remote staging
$ git push staging master

$ git checkout -b development

Then the workflow is as easy as:

commit features’ stuff on `development`
merge `development` into `staging`
push `staging` into remote `staging/master`
merge `staging` into `master`
push `master` to remote `production/master`

Now I need a way to setup environment specific settings, here is the pattern I used:

myproject/settings.py:

import os
import imp
import socket
import subprocess


LOCAL_HOSTNAMES= ('myhost',)
HOSTNAME = socket.gethostname()

PROJECT_ROOT = os.path.dirname(os.path.realpath(__file__))

def get_environment_file_path(env):
    return os.path.join(PROJECT_ROOT, 'config', '%s.py' % env)

if 'APP_ENV' in os.environ:
    ENV = os.environ['APP_ENV']
elif HOSTNAME in LOCAL_HOSTNAMES:
    branch = subprocess.check_output(
        ['git', 'rev-parse', '--abbrev-ref', 'HEAD']).strip('\n')
    if os.path.isfile(get_environment_file_path(branch)):
        ENV = branch
    else:
        ENV = 'development'

try:
    config = imp.load_source('env_settings', get_environment_file_path(ENV))
    from env_settings import *
except IOError:
    exit("No configuration file found for env '%s'" % ENV)

Then I can put my common settings into settings.py and specific settings into config/{branch}.py

To get it work on remote env, just set the APP_ENV this way:

$ heroku config:add APP_ENV=staging --remote staging
$ heroku config:add APP_ENV=production --remote production

That’s it, the application now switches to the appropriate config file for current branch and can be override by setting APP_ENV environment variable.

django-compressor feat. django-storages

The other tip I’ll show you here is to configure django-compressor and django-storages to work together on previous set environments.

The expected behaviours I need:

When settings.DEBUG is True:
- statics have to be delivered by the application (or heroku nginx on remotes).
- compressor has to be disabled
When settings.DEBUG is FALSE:
- statics have to be delivered by Amazon S3 CDN.
- compressor has to be enabled and upload compressed assets to S3

As compressor use “locally collected” statics, I need to collect it locally on remotes to, lets create a custom storage class, myproject/myapp/storage.py:

from django.core.files.storage import get_storage_class
from storages.backends.s3boto import S3BotoStorage

class CachedS3BotoStorage(S3BotoStorage):
    """S3 storage backend that saves the files locally, too.
    """
    def __init__(self, *args, **kwargs):
        super(CachedS3BotoStorage, self).__init__(*args, **kwargs)
        self.local_storage = get_storage_class(
            "compressor.storage.CompressorFileStorage")()

    def save(self, name, content):
        name = super(CachedS3BotoStorage, self).save(name, content)
        self.local_storage._save(name, content)
        return name

Then I add settings this way:

LOCAL_HOSTNAMES= ('myhost',)
# Statics
STATIC_URL = '/static/'

STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')

MEDIA_ROOT = os.path.join(STATIC_ROOT, 'media')
MEDIA_UPLOAD_ROOT = os.path.join(MEDIA_ROOT, 'uploads')

MEDIA_URL = STATIC_URL + 'media'

# Compressor
COMPRESS_ENABLED = DEBUG is False
if COMPRESS_ENABLED:
    COMPRESS_CSS_FILTERS = [
        'compressor.filters.css_default.CssAbsoluteFilter',
        'compressor.filters.cssmin.CSSMinFilter',
    ]
    COMPRESS_STORAGE = 'myapp.storage.CachedS3BotoStorage'
    COMPRESS_URL = STATIC_URL
    COMPRESS_OFFLINE = True

# Storages
if not DEBUG and HOSTNAME in LOCAL_HOSTNAMES:
    STATICFILES_STORAGE = 'myapp.storage.CachedS3BotoStorage'

Then add this lines on myproject/config/development.py:

if not DEBUG:
    STATIC_URL = 'https://xxx-dev.s3.amazonaws.com/'

AWS_ACCESS_KEY_ID = "xxxxxxxxxxxxx"
AWS_SECRET_ACCESS_KEY = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
AWS_STORAGE_BUCKET_NAME = "xxx-dev"

And modify the Profile this way:

web: python project/manage.py collectstatic --noinput; python myproject/manage.py compress; python myproject/manage.py run_gunicorn -b "0.0.0.0:$PORT" -w 3

Ok, so now, to collect static over S3 I just need to set myproject.config.{branch}.DEBUG to False and then run:

$ python myproject/manage.py collectstatic --noinput

Note: collecting statics via a `worker` is probably a better practice but it will increase your heroku bills…

Hope this will help you.

See you.

Building frontend web applications using backbone.js & brunch.io

2012-02-02T00:00:00-08:00

Last sunday I decided to grow up my javascript skills by playing with modern and cool libraries.

I planned to test:

a language abstraction (coffeescript)
a frontend MVC framework that deals with RESTful APIs (spine.js, backbone.js)
a template engine (eco, coffeekup)

First of all, I tried spine.js that is a frontend framework that provides:

bootstrapping tools (project generation…)
views
models
routing
testing tools
…

But I trashed it cause of hard jQuery dependency (<troll>I hate jQuery</troll>).

So, next I discovered brunch.io that is a backbone.js projects bootstrapper that does quite the same things as spine.js with the possibility to replace jQuery by zepto.js.

The stack here is composed of:

underscore.js
backbone.js
jasmine
coffeescript
css tools (boilerplate…)
brunch.io (project configuration and class bootsrapping)

Test project

My favorite RESTful API to test new client is github’s one, cause it has been well designed and CORS requests are allowed.

If you planned to write a client side application on top of that kind of library, make sure the service is consumable via XHR, otherwise you’ll have to make a server side “reverse proxy application”, and then doing the job client side will make no sence (IMHO).

Lets start the project:

$ npm install -g brunch
$ brunch new issues
$ cd issues

Now directory tree and configs has been created with default assets.

$ brunch watch --server

runs an express.js instance that delivers compiled files (just open http://localhost:3000 in your favorite browser).

Backbone main concepts

Routers

Backbone routers is the navigation layer that links UI actions to the views.

Sample router:

class exports.MainRouter extends Backbone.Router
  routes :
    ':username/:repository': 'repository'
    '': 'repository'

  repository: (username, repository) ->
    app.repositoryView.render(username, repository).el

Views

Views are controller classes that deal with your business models and the UI. Each view as an `el` member that is the DOM element where rendering will be displayed.

Starting a view via brunch.io:

$ brunch generate view issue_list_view

Then with a piece of logic:

{IssueView} = require 'views/issue_view'
{Issues} = require 'collections/issues'

issueListTemplate = require './templates/issue_list'


class exports.IssueListView extends Backbone.View
  el: 'section:first'

  initialize: (repository) ->
    @issues = new Issues
    @issues.url = repository.get 'url'
    @issues.url+= '/issues'
    @issues.bind 'reset', @addAll

  render: =>
    issues = @issues.fetch()
    @$(@el).html issueListTemplate
    this

  addOne: (issue) =>
    view = new IssueView model: issue
    $(@el).find('#issues tbody:first').append view.render().el

  addAll: =>
    @issues.each @addOne

Models

A model is a business entity, that is linked to an HTTP ressource using the `url` attribute.

May be persisted and fetched from local storage to.

$ brunch generate model issue

Sample:

class exports.Issue extends Backbone.Model
  ul: '/path/to/issue/ressource'

  defaults:
    title: 'New issue'
    body: null

Collections

Collection is a set of model objects, as models, they may be linked to an HTTP ressource.

That’s all for basics. For now, my application only lists issues for a given project. I’ll maybe add more features (like create / update / delete issues) later. You’ll find a live demo here.

See you.

Django real world functional testing

2012-01-20T00:00:00-08:00

In the real world, a django application may be deployed on a real production plateform with as many layers as needed:

WSGI server
proxy
…

When we write functional tests with the dummy web client, we do not cover what’s going on over all those layers that composed application globality.

Also, in the real world, we use web client intances such as browsers like chromium, opera, IE… to deal with the application over HTTP and we want our application to run correctly on all those clients.

Another important point is the use of client side javascripts: when we use the dummy client, we can’t test javascripts.

That’s why we need to write functionnal tests that cover real world constraints.

Django 1.4 will bring us tools to do the job.

Lets write a demo application

To simply illustrate this, I’ve made a simple (useless) application composed of a single user story:

As an anonymous user, I can write a message, then the message is displayed in a list with the nine latest messages.

models.py:

from django.db import models
from django.core.urlresolvers import reverse


class Post(models.Model):
    message = models.CharField(max_length=140)
    author = models.CharField(max_length=50)
    created_at = models.DateTimeField(auto_now=True, auto_now_add=True,
        db_index=True)

    def get_absolute_url(self):
        return "%s#%s" % (reverse('home'), str(self.id))

views.py:

from django.views.generic.edit import CreateView
from models import Post
from settings import LATEST_POSTS_COUNT


class HomeView(CreateView):
    model = Post
    template_name = 'home.html'

    def get_context_data(self, **kwargs):
        context = super(HomeView, self).get_context_data(**kwargs)
        context['posts'] = Post.objects\
            .order_by('-created_at')[:LATEST_POSTS_COUNT]
        return context

Ok, now, I’ll write a functional test case basically using the dummy client:

from django.core.urlresolvers import reverse
from django.test import TestCase
from models import Post


class HomeTest(TestCase):
    def test_post_submission(self):
        initial_posts_count = Post.objects.count()
        r = self.client.post(reverse('home'), {
            'message': u'Hello world!',
            'author': u'jeanphix',
        }, follow=True)
        self.assertContains(r, '0 minutes ago')
        self.assertContains(r, 'Hello world!')
        self.assertEqual(initial_posts_count + 1, Post.objects.count())

Ok, the application now works correctly, but I think it’s gonna be better to do the job ansynchronous. So, let’s add a piece of javascript:

window.addEvent('domready', function() {

    var form = document.id('message-form');
    form.addEvent('submit', function(e) {

        var request = new Request.JSON({
            url: form.action,

            onSuccess: function(datas) {
                form.getElements('.errorlist').each(function(element) {
                    element.destroy();
                });
                if (datas.errors) {
                    // Form is not valid
                    Object.each(datas.errors, function(value, key) {
                        var input = document.id('id_' + key);
                        var previous = input.getParent('p').getPrevious();
                        var errorlist = new Element('ul', {
                            'class': 'errorlist',
                            html: '<li>' + value[0] + '</li>'
                        }).inject(input.getParent('p'), 'before');
                    });
                } else {
                    // New post has been created
                    var postList = document.id('post-list');
                    if (!postList) {
                        postList = new Element('ul', {'class': 'post-list'}).inject(form, 'after');
                    }
                    var li = new Element('li', {
                        id: datas.id,
                        html: '0 minutes ago ' +
                        '<span class="author">' + datas.author + '</span> wrote:' +
                        '<blockquote>' + datas.message + '</blockquote>'
                    }).inject(postList, 'top');
                    form.getElement('textarea').set('value', '').focus();
                }
            }
        }).post(form);
        e.stop();
    });
});

and then modify views.py to feet my need:

from django.views.generic.edit import CreateView
from django.http import HttpResponse
from django.utils import simplejson as json
from models import Post
from settings import LATEST_POSTS_COUNT


class HomeView(CreateView):
    model = Post
    template_name = 'home.html'

    def get_context_data(self, **kwargs):
        context = super(HomeView, self).get_context_data(**kwargs)
        context['posts'] = Post.objects\
            .order_by('-created_at')[:LATEST_POSTS_COUNT]
        return context

    def form_valid(self, form):
        resp = super(HomeView, self).form_valid(form)
        if self.request.is_ajax():
            datas = {'id': self.object.id, 'message': self.object.message,
                'author': self.object.author}
            return self.get_json_response(datas)
        else:
            return resp

    def form_invalid(self, form):
        if self.request.is_ajax():
            errors = {'errors': dict(form.errors)}
            return self.get_json_response(errors)
        else:
            return super(HomeView, self).form_invalid(form)

    def get_json_response(self, datas):
        return HttpResponse(json.dumps(datas), content_type='application/json')

Now my application works correctly even when javascript is disabled. Now it’s gonna be cool to write a functionnal test to cover that.

LiveServerTestCase

Django 1.4 introduced a new test class called LiveServerTestCase that extends TransactionTestCase.

This new test class launches the application in a real WSGI server instance into an asynchronous thread. As it’s a real server, we can easily write tests within real web browser instances.

There are many solutions providing python backends (Ghost.py, Selenium…), here I’m gonna use Selenium.

So, I had a new (minimalist) test case:

from django.test import LiveServerTestCase
from models import Post

from selenium.webdriver.firefox.webdriver import WebDriver
from selenium.webdriver.support.ui import WebDriverWait


class BaseLiveTest(LiveServerTestCase):
    @classmethod
    def setUpClass(cls):
        cls.selenium = WebDriver()
        super(BaseLiveTest, cls).setUpClass()

    @classmethod
    def tearDownClass(cls):
        super(BaseLiveTest, cls).tearDownClass()
        cls.selenium.quit()


class LiveHomeTest(BaseLiveTest):
    def test_post_submission(self):
        initial_posts_count = Post.objects.count()
        self.selenium.get(self.live_server_url)
        message = self.selenium.find_element_by_name("message")
        message.send_keys('my message')
        self.selenium.find_element_by_name("author").send_keys('jeanphix')
        self.selenium.find_element_by_xpath('//input[@value="Send"]').click()
        WebDriverWait(self.selenium, 10).until(
            lambda x: self.selenium.find_element_by_css_selector('ul li'))
        self.assertEqual(initial_posts_count + 1, Post.objects.count())

As you can see, we can deal with database and browser in the same script…

That’s all for now.

Faking geolocation javascript API using Casper.js

2011-11-16T00:00:00-08:00

Testing frontend javascript map behaviours and geolocation stuff is not an easy thing to do.

Casper.js, that come on top of Phantom.js, is a great tool for quickly write functionnal tests, including frontend javascript behaviours cover as it provides an API to access real DOM state.

As QtWebKit doesn’t deal with javascript geolocation API, we need to write a fake location service in order to test user position changes.

var addFakeGeolocation = function(self, latitude, longitude) {
    self.evaluate(function() {
        window.navigator.geolocation = function() {
            var pub = {};
            var current_pos = {
                coords: {
                    latitude: window.__casper_params__.latitude,
                    longitude: window.__casper_params__.longitude
                }
            };
            pub.getCurrentPosition = function(locationCallback,errorCallback) {
                locationCallback(current_pos);
            };
            return pub;
        }();
    }, { latitude: latitude, longitude: longitude });
};

will add the expected geolocation faked provider.

Now it’s as easy as ever to test user move:

casper.then(function(self) {
    addFakeGeolocation(self, 12, 35);
    self.assertEval(function() {
        // Check expected changes
    });
});

OUPS! un bug dans mon backlog!

2011-06-01T00:00:00-07:00

Au cours de son excellente conférence l’anatomie d’une mission agile durant laquelle il nous a exposé ses retours d’expériences sur le déploiement de l’agilité au sein d’une société d’édition logiciel, Pablo Pernot a évoqué son échec sur la mise en place d’un KanBan pour la gestion des défauts.

Il est en effet fréquent de constater la mise en place d’un workflow de traitements des bugs dissocié de la gestion centrale du projet. Dans son cas, la gestion du projet était outillée par SCRUM qui est axé autour d’un backlog de produit.

Rappelons rapidement ce qu’est un backlog de produit:

Un backlog est tout simplement une liste récursive (arborescence) des éléments qui devront composer le produit: fonctionnalités, tests, cas d’utilisations, tâches… plus généralement, c’est une vision à l’instant t de ce que sera le produit dans son état final (et englobe donc ce qu’est le produit dans son état actuel, le cas échéant, il faut se poser des questions…).

Au cours des phases de production, les éléments consituants le backlog sont traités individuellement par l’équipe en respectant un workflow précis garant de la qualité.

Exemple de ce que pourrait être le workflow de traitement d’un élément du backlog:

priorisation
plannification
développement
test
dépôt dans la release suivante

Qu’est-ce qu’un bug?

Un bug est un défaut (visuel, fonctionnel, sécuritaire…) livré sur une release du produit. Généralement il est livré involontairement par l’équipe de production et remonté par les utilisateurs.

Malheureusement, il fait lui aussi partie intégrante du produit.

La correction d’un bug, au même titre que le développement d’une nouvelle fonctionnalité, consomme des ressources. Il est donc tout naturel de penser à en planifier son traitement et à définir un workflow de correction.

Attention: Un défaut sur une fonctionnalité en cours de développement n’est pas un bug

Exemple de ce que pourrait être le workflow de traitement d’un bug:

priorisation
plannification
écriture de tests fonctionels et/ou unitaires reproduisant le bug
correction
mise en production
dépôt dans la release suivante

Concrètement, un bug a toutes les caractéristiques nécessaires à son intégration dans le backlog de produit:

il qualifie le produit
il est planifiable
il nécessite la définition d’un workflow de traitement
il peut être rattaché à une fonctionnalité (ou autre élément du backlog)

Il est donc tout à fait cohérent de fusioner la gestion des développements de nouvelles fonctionnalités à celle de la correction des bugs et donc: d’intégrer les bugs au backlog de produit et de mutualiser l’outillage.

Un petit exemple de ce que pourrait être un backlog incluant un bug:

#feature accounts
- #feature registration
  - #story as an anonymous user I can register new account
    - #task create registration form
      - #defect doesn’t prevent CSRF
- #feature authentication
  …

Reordering datas extracted using postgres WITH RECURSIVE

2010-10-29T00:00:00-07:00

Building python tree dict from postgres with recursive queries look quite simple, but it’s not!

def _nestify(entities) :
    """Transforms nested collection into tree list.
    """
    class entitydict(dict):
        """Dot access dict class.
        """
        def __getattr__(self, attr):
            return self.get(attr, None)
        __setattr__= dict.__setitem__
        __delattr__= dict.__delitem__

        def __init__(self, *args):
            self.children = []
            super(entitydict, self).__init__(*args)

    if not len(entities):
        return []

    root_level = entities[0].level
    nested = []
    depth = {}
    for entity in entities:
        entity = entitydict(entity)
        depth[entity.level - root_level]=entity
        if entity.level == root_level :
            #is root
            nested.append(entity)
        else :
            parent = depth[entity.level - root_level - 1]
            parent.children.append(entity)
    return nested

Designing trees in mongodb using mongodm

2010-10-08T00:00:00-07:00

why mongodm?

mongodm is a small API on top of pymongo that allowed to create user defined mongodb object documents.

All collection’s queries are still made using pymongo, mongodm just provide an nice way to create data structures and validation schemas.

The first reason that bring me away from the great mongoengine is that’s there’s no way to easily manage recursive trees.

Here are two tree pattern implementation using this small library.

Full Tree in Single Document

code sample:

from mongodm.connection import Connection
from mongodm.fields import StringField, ListField
from mongodm.document import Document, EmbeddedDocument


connection = Connection('localhost', 27017)
db = connection['test-database']


class TreeNode(EmbeddedDocument):
    label = StringField()
    children = ListField('TreeNode')


class Tree(Document):
    __collection__ = 'trees'
    __db__ = db
    label = StringField()
    children = ListField('TreeNode')


tree = Tree()
tree.label = 'root'


first_child = TreeNode()
first_child.label = 'node 1'
tree.children.append(first_child)


second_child = TreeNode()
second_child.label = 'node 1.1'
first_child.children.append(second_child)


third_child = TreeNode()
third_child.label = 'node 1.2'
first_child.children.append(third_child)


Tree.collection().insert(tree)

mongodb datas:

> db.trees.find()
{ "_id" : ObjectId("4caebee27478f70e7d000000"), "children" : [
        {
                "children" : [
                        {
                                "children" : [ ],
                                "label" : "node 1.1"
                        },
                        {
                                "children" : [ ],
                                "label" : "node 1.2"
                        }
                ],
                "label" : "node 1"
        }
], "label" : "root" }

Materialized paths pattern

code sample:

from mongodm.connection import Connection
from mongodm.fields import StringField, ReferenceField
from mongodm.ext.tree import TreeDocument


connection = Connection('localhost', 27017)
db = connection['test-database']


class TreeNode(TreeDocument):
    __collection__ = 'nodes'
    __db__ = db
    label = StringField()
    parent = ReferenceField('TreeNode')


TreeNode.collection().ensure_index('path') #don't forget to create index on path field


root_node = TreeNode()
root_node.label = 'root'
TreeNode.collection().insert(root_node)


first_child = TreeNode()
first_child.label = 'node 1'
first_child.parent = root_node
TreeNode.collection().insert(first_child)


second_child = TreeNode()
second_child.label = 'node 1.1'
second_child.parent = first_child
TreeNode.collection().insert(second_child)


third_child = TreeNode()
third_child.label = 'node 1.2'
third_child.parent = first_child
TreeNode.collection().insert(third_child)

mongodb datas:

> db.nodes.find()
{ "_id" : ObjectId("4caeba3b7478f70cb9000000"), "parent" : null, "level" : 0, "label" : "root", "priority" : 0, "path" : "" }
{ "_id" : ObjectId("4caeba3b7478f70cb9000001"), "parent" : { "$ref" : "nodes", "$id" : ObjectId("4caeba3b7478f70cb9000000") }, "level" : 1, "label" : "node 1", "priority" : 0, "path" : "4caeba3b7478f70cb9000000," }
{ "_id" : ObjectId("4caeba3b7478f70cb9000002"), "parent" : { "$ref" : "nodes", "$id" : ObjectId("4caeba3b7478f70cb9000001") }, "level" : 2, "label" : "node 1.1", "priority" : 0, "path" : "4caeba3b7478f70cb9000000,4caeba3b7478f70cb9000001," }
{ "_id" : ObjectId("4caeba3b7478f70cb9000003"), "parent" : { "$ref" : "nodes", "$id" : ObjectId("4caeba3b7478f70cb9000001") }, "level" : 2, "label" : "node 1.2", "priority" : 0, "path" : "4caeba3b7478f70cb9000000,4caeba3b7478f70cb9000001," }

you can easily get back children using TreeDocument.children property.

I’m working on mongodm on my time off for a personnal project (this is one of my first python developments), so feel free to give me your feed back.