Разбор

Наткнулся на StackOverflow на вопрос, который давно мучил и меня самого: как в dgrid обрабатывать двойной клик по строке? Встроенного обработчика события onDblClick в классах библиотеки не было, поэтому я решил посмотреть, можно ли что-то сделать с помощью подручных средств.

Посмотрев код библиотеки, я обнаружил, что у класса Grid есть методы row() и cell(), возвращающие информацию о строке и ячейке соответственно при передаче в качестве параметра события, которое произошло в таблице. Главная сложность была в определении того, на что ставить обработчик. Понятно, что для тысяч строк нельзя вешать onClick() на каждую строку. В этом случае на контейнер вешают один единственный обработчик, который смотрит на то, от кого пришло событие, и уже тогда что-то делает. Всё оказалось не так уж сложно.

define([
    "dojo/_base/declare",
    "dojo/_base/lang",
    "dgrid/Grid"
], function(declare, lang, Grid){
    return declare(Grid, {
        onDblClick: function(){
            /* Функция-пустышка, которая должна быть заменена на настоящую в классах,
               унаследованных от этого. Тут должна быть какая-то работа с переданным
               объектом, состоящим из трех полей:
               - id      - id записи, если есть
               - data    - полный объект из связанного с таблицей Store
               - element - DOM-элемент, на котором случился двойной клик               */
        },

        _onDblClick: function(event){
            /* Вызываем onDblClick, передав "чистый" объект с параметрами. Обычно тут 
               разработчики Dojo Toolkit рекомендуют дополнительно вызывать on.emit с
               необходимыми параметрами. На случай, если кто-то ещё должен слушать 
               события, происходящие в таблице, и как-то на них реагировать           */
               this.onDblClick(this.row(event));
        }, // _onDblClick

        postCreate: function(){
            // Установка обработчиков на построенную DOM-модель таблицы
            this.inherited(arguments);

            this.on(".dgrid-content .dgrid-row:dblclick", lang.hitch(this, "_onDblClick"));
        } // postCreate
    }); // declare
}); //define

Можно пойти дальше и создать класс-расширение, раз уж в Dojo реализовано множественное наследование. Если что, это рекомендуемый способ расширения функционала классов и каноничный подход к написанию плагинов.

В Dojo Toolkit все базовые настройки приложения хранятся в глобальном объекте dojoConfig, и его инициализация должна происходить раньше, чем будет подключена сама библиотека Dojo, потому что при загрузке выполняется код, который проверяет существование этой переменной. В итоге пришёл к вот такому конфигу:

(function(G) {
    "use strict"; // Возможно, избыточно, поскольку весь Dojo написан без этой директивы

    G.dojoConfig = {
        async: true,        // Для всех браузеров должно быть так
        parseOnLoad: false, // Разбор страницы на виджеты при загрузке? Лучше дождаться domReady
        debug: true, 
        // Самая сложная часть - определение текущей локали браузера. Влияет на всякие
        // внутренние механизмы Dojo, например, какой язык будет использован для виджетов.
        // Хотите календарь на русском языке? Первый день недели - понедельник? Это сюда.
        // Можно и явно указать "ru-ru", но мне нравится вот такой подход.
        locale: navigator.language || navigator.userLanguage
    };
})(this); // this === window

Я довольно часто пользуюсь Dgrid. Это довольно мощная таблица, однако, у нее есть ряд недостатков, которые решаются обходными путями, например, через редактирование стилей. Вот так можно задать автоматическое растягивание таблицы по размеру родительского блока:

.dgrid {
    position: absolute;
    top: 0;
    bottom: 0;
    left: 0;
    right: 0;
    height: auto;
}

Решение проблемы взято со StackOverflow.

Но есть другая проблема. Допустим, мы решили разместить DGrid внутри компонента типа ContentPane. При отображении заголовок будет сжат в 0 и наедет на данные. Можно изменить размер окна браузера, чтобы отображалось нормально, а можно:

var cpWithDgrid = new ContentPane({
    buildRendering: function() {
        this.inherited(arguments);
        this.grid = new DGrid({}); // Подставьте свой класс для Grid'а
        this.set("content", this.grid);
    },

    resize: function() {
        this.inherited(arguments);
        this.grid.resize();
    }
});

А разгадка такого поведения очень проста: высота элементов таблицы DGrid вычисляется до помещения в DOM, а потому они получают 0 в качестве значения. DGrid, разумеется, под суд. По-хорошему, при запуске вашего виджета он должен всем дочерним виджетам дать команду пересчитать размеры, но конкретно с DGrid это почему-то не работает. Костыль? Костыль. Но работает.

Надо ещё про работу с Rest сказать. Мои таблицы получают данные с сервера. В поле collection в качестве значения я указываю экземпляра класса-наследника dstore/Rest. Самое интересное, что при получении данных с сервера в логах часто можно увидеть сообщение об ошибке: Store reported null or undefined totalLength. Make sure your store (and service, if applicable) are reporting total correctly! Разумеется, это не правда. На самом деле DGrid ожидает увидеть в ответе сервера поле total, а не totalLength.

Поскольку на сервере у меня обычно Django + Django REST Framework, нужно соблюдать его требования. Одним из них является завершающий слеш в конце любого запроса. В итоге создал миксин, с которым смешиваю все создаваемые мной классы-наследники dstore/Rest:

define([
    "dojo/_base/declare"
], function(declare) {
    return declare(null, {

        ascendingPrefix: "",

        _getTarget: function(id) {
            // По требованиям DRF в конце URL должен стоять /
            var target = this.target;

            // А можно решить с помощью строковых литералов {$id}, но не буду
            if (target.slice(-1) == '/') {
                return target + id + '/';
            } else {
                return target + '/' + id + '/';
            } // fi
        } // _getTarget
    }); // declare
}); // define

Постоянно забываю, как в Dojo Toolkit 1.x автоматически цеплять CSRF-Token к XHR-запросам. Ниже просто код, который должен запускаться при старте приложения (FrontEnd).

require([
  "dojo/cookie",
  "dojo/request/notify",
  "dojo/domReady!"
], function(cookie, notify) { 
  notify("send", function(response, cancel) {
    response.xhr.setRequestHeader("X-SCRFToken", cookie("csrftoken"));
  });
});

И каждый раз забываю, как правильно выставить CSRF-Token в Django. Для этого нужно не так уж и много:

# -*- coding: utf-8 -*-

u"""Набор видов для построения базового интерфейса приложения."""

from django.shortcuts import render_to_response
from django.views.generic import View
from django.core.context_processors import csrf


class Index(View):

    u"""Главное окно приложения."""

    template_name = "index.html"

    def get(self, request):
        # Установка CSRF-токена
        c = {}
        c.update(csrf(request))
        return render_to_response(self.template_name, c)

Но этого мало. Нужно ещё в теле главной страницы разместить скрытое поле, куда будет записан токен. Кстати, только так в старых версиях Django можно указать cookie для его хранения.

<!doctype html>
<html lang="ru">
  <head>
    <meta charset="UTF-8"/>
    <title>Установка CSRF-Token'а</title>
  </head>
  <body>
    <!-- ТО САМОЕ СКРЫТОЕ ПОЛЕ -->
    <input name="csrftoken" type="hidden" value="{% csrf_token %}" />
    <!-- /ТО САМОЕ СКРЫТОЕ ПОЛЕ -->
  </body>
</html>

Немного о Dojo Framework

Введение

Dojo Dramework - проект, ведущий свою историю с 2004 года. Причиной, побудившей авторов создать его, стала политика фирмы, где они тогда работали: Sencha хотела денег, и в общем-то, цели своей достигла, на их странице можно полюбоваться совершенно нескромными ценами на ExtJS, они же хотели сделать библиотеку бесплатной

Так и не решив проблему мирным путём, группа энтузиастов откололась, чтобы создать свой собственный фреймворк, что им очень даже удалось.

Обзор возможностей

"Из коробки" Dojo содержит практически весь тот функционал, что мы можем найти в jQuery. Правда, вместо $() там используется dojo.query(), но суть не в этом - это лишь малая часть того, что Dojo на самом деле умеет.

Асинхронная подгрузка модулей

Последние 2 года я читаю о том, что в Angular 2 будет реализована асинхронная подгрузка модулей. В Dojo эта фича была реализована в 2009, но не позиционировалась как "серебрянная пуля", в отличие от. Скажу даже больше, это самый что ни на есть базовый функционал. Всё приложение не просто можно, а даже нужно разбивать на маленькие модули. Люди, знакомые с require.js, оценят написанный ниже код:

require([
      "dojo",
      "dojo/domReady!"
], function(
    dojo
){
    dojo.query("div.centered").style({
      color: "orange",
      textWeight: "bold"
    });
});

Классическое наследование

Стоян Стефанов в своей книге "JavaScript. Шаблоны" выразил мысль о том, что для подготовленного программиста наследование через прототип, используемое в JS, является более мощным, чем классическое (через классы). Не могу с ним согласиться, поскольку сама концепция является довольно спорной.

Существует множество способов обойти прототипное наследование JavaScript, и один из них предлагает Dojo. И не просто предлагает, а так же реализует концепцию множественного наследования, когда результирующий класс получает все свойства и методы своих родителей. Для объявления класса в Dojo имеется метод declare(). С его помощью можно очень легко создать новый "класс" (не в том смысле, в каком мы понимаем его говоря о языках с чистым классическим наследованием, например, C++ или Python, а лишь его эмуляцию).

Именно данный метод Dojo предлагает использовать для создания виджетов, о чём сказано ниже.

Dijit и Dojox

Dijit

Dijit представляет собой готовую библиотеку виджетов, входящую в официальную поставку Dojo. В комплекте идёт несколько тем и базовые контролы, необходимые для создания Rich Interface Applications - кнопки, меню, диалоговые окна (опять эмуляция, ясное дело), поля выбора, деревья, списки, панели... Лучше посмотрите сами вот здесь.

Можно создавать свои собственные компоненты (виджеты) на основе имеющихся. Есть даже базовые классы - _BaseWidget, _TemplatedMixin и другие. Да, здесь нет директив из мира Angular, и контроллеров тоже. И сервисов нет, о, Боже, я в аду! Если нам нужно использовать какой-то виджет, мы пишем в свойстве элемента DOM, например, data-dojo-type="dijit/form/Button", и получаем кнопку. Соответственно, нет здесь и проблем с приоритетом директив, и возни с transclude, контролллерами и прочими столь милыми сердцу фанатов Angular надстройками над языком, которые ко второй версии весело отомрут, будучи заменены Web-компонентами.

Dojox

Как я понял, это набор не входящих в официальную поставку виджетов. Авторы могут поддерживать, а могут и не поддерживать их. Исправление ошибок? Новые фичи? Какой-то Road Map? Всё на совести автора, никто ничего не обещает. Однако, библиотека и набор возможностей впечатляют.

Причины непопулярноcти Dojo

Причин множество, я остановлюсь на тех, которые кажутся мне наиболее явными и значительными. Отсортированы в порядке всплытия в памяти.

Скудная документация

Документация к Dojo не просто бедная, а очень бедная. Некоторые статьи были написаны ещё в нулевых, и с тех пор ни разу серьёзно не перерабатывались. Литература? Самое свежее, что я видел - книга 2009 года. От жизни отстала очень сильно.

Высокий порог вхождения

Angular не может похвастать доброжелательностью к новичкам, однако, даже там, сев вечером с кружкой чая ближе к ночи уже можно сделать что-то более-менее работающее. В случае с Dojo ситуация совершенно иная. Фреймворк требует долгого, настойчивого изучения. Используемые в нём подходы серьёзно отличаются от тех, к которым привыкли пользователи Angular и jQuery.

Слабый пиар

В отличие от Google, пихающего свой Angular буквально везде, IBM - один из основных спонсоров проекта - практически никак его не продвигает. Попробуйте сами найти на YouTube какой-нибудь dojoConf или вебинар по новым возможностям. Может быть, у вас получится найти how-to или разбор сложного примера? Дайте мне ссылку! В основном всё, что я находил, описывается следующим образом: "Вот смотрите, числа обладают свойствами коммутативности. 2+2=4. Зная это, не трудно доказать теорему Ферма". Другими словами, пропущен средний уровень, порой даже складывается впечатление, что спецов, которые могут написать высококачественную статью про Dojo и имеют на это время, свободное от загребания бабла, попросту не существует.

Итоги

Так стоит ли тратить время на этот фреймворк?

Сейчас я не готов ответить на этот вопрос однозначно. Свой новый проект я начал писать на нём, и пока дело не сильно продвинулось. Однако, как мне кажется, Dojo именно тот проект, на который стоит равняться. Многие идеи, которые первыми появились именно в нём, впоследствии были заимствованы другими фреймворками. Исходный код и сама структура проекта (а так же виджетов Dijit) являются хорошим образцом продуманного, профессионального подхода. Стиль, модульность, комментарии - всё это выполнено блестяще.