Jii — JavaScript фреймворк с архитектурой от Yii 2


    Вступление


    Привет всем хабровчанам, любителям Yii и Node.js.
    Продалжаю серию статей про фреймворк Jii и его части. В прошлых частях мы рассмотрели части фреймворка, которые можно использовать без инициализации приложения, а именно — Query Builder и Active Record. Из голосования (а так же писем и комментариев) стало понятно, что продолжать стоит. И на этот раз мы будем говорить о архитектуре и структурных составляющих фреймворка Jii.

    Идеология



    Перенос функционала фреймворка с PHP на JavaScript — не тривиальная задача и не может выполниться роботом. Языки имеют очень разные возможности и отличия, главным из которых является асинхронность JavaScript.
    Ниже о том, как решались эти проблемы и каких практик я придерживался. Этих же практик стоит придерживаться другим разработчикам при разработке Jii и его разширений.

    Promise


    Каждая асинхронная операция возвращает Promise объект, имплементирующий стандарт ES6. Для этого используется библиотека when.
    Методы, начинающиеся с префикса load (loadData()) возвращают Promise, методы с приставкой get (getUser(), get('id')) — возвращают данные синхронно.

    Сохранение API Yii 2


    Изначальная идея Jii заключается в том, чтобы перенести прекрасный и насыщенный PHP фреймворк на JavaScript. Чтобы php-разработчики, желающие попробовать/перейти на node.js могли быстро и без труда освоить фреймворк на
    другом языке программирования, даже без чтения класс референс!

    Встраиваемость


    Jii проектируется с учётом того, что он должен работать везде где можно — браузер, сервер, phonegap, node-webkit и т.п.
    Не смотря на то, что Yii генерирует не мало глобальных констант (YII_*), класс Yii и неймспейс yii, Jii не засоряет
    глобальное пространство. Браузерам доступен единственный объект Jii, который можно спрятать, вызвав Jii.noConflict(). В серверной части в global ничего не пишется, а Jii возвращается как результат
    вызова require('jii').

    Npm пакеты


    Jii распространяется как набор пакетов jii-* и не имеет собственных пакет-менеджеров (привет, Meteor). Это значит, что вместе с Jii вы можете подключить любые другие npm пакеты.
    Jii разбит на несколько пакетов, поэтому его можно использовать по частям. Например, если вы хотите начать использовать только ActiveRecord, то вы устанавливаете jii-ar-sql и не имеете контроллеров, вьюшек, http сервера и прочего ненужного вам кода.
    Если вы читали предыдущие статьи, то уже убидились в этом.
    Основными пакетамы Jii на данный момент являются:

    Геттеры и сеттеры


    Одной из основных фишек Yii является легкость доступа к свойствам и методам объектов через геттеры и сеттеры, например, обращаясь через $model->user можно получить или свойство модели, или вызвать метод getUser(), или вообще получить отношение user, где произойдет обращение к БД — магия полнейшая, но всем она нравится.
    В JavaScript'е не все браузеры поддерживают геттеры и сеттеры, а во многих проектах нужно еще поддерживать IE8, поэтому в Jii они реализованы в виде методов get('user') и set('user', 'Ivan'). Такой подход можно встретить во многих библиотеках, например в Backbone.
    В будущем, когда необходимость в старых браузерах отпадет — то настоящие геттеры и сеттеры добавятся паралельно с get/set методами, которые будут через них и работать.

    Классы и неймспейсы


    Как говорится, каждый уважающий себя программист должен написать свою реализацию классов в JavaScript. Так и тут, для реализации классов используется моя библиотека Neatness, которая уже хорошо показала себя в других внутренних проектах.

    Почему не ES6 classes (и не CoffeeScript/TypeScript)?



    В комментариях и на гитхабе уже есть небольшой холивар по этому поводу.
    Озвучу и здесь причины отсутствия ES6 в Jii:
    1. Для node.js нужен препроцессинг (io.js поддерживает)
    2. В es6 нет неймспейсов, а они нужны для повторения фич Yii. Их можно имплементировать через модули, но это будет костыль. Менять один костыль на другой — нет смысла.
    3. В ES6 захочется использовать геттеры и сеттеры, но они не поддерживаются старыми браузерами, как говорилось выше
    4. Многие разработчики не знают формата es6/coffeescript/typescript и это будет дополнительный порог вхождения
    5. Сложность работы с кодом разных форматов (ES5 и ES6). Не всегда есть возможность в существующем проекте поменять весь код на es6, а наследовать es6 классы все равно нужно, и все равно прийдется использовать Jii.defineClass() для создания классов — костыль не уходит.

    Ниже я добавил опрос на эту тему, голосуйте, комментируйте!

    Middlewares


    В Yii фреймворке компоненты доступны глобально через Yii::$app->… Однако в Jii не все компоненты можно расположить глобально, т.к. некоторые из них (Request, Response, WebUser, Session, …) привязаны к контексту (запросу).
    Такие компоненты будут создаваться в контексте (Jii.base.Context) и передаваться в качестве параметра в action — аналогия с передачей request и response в express.

    /**
     * @class app.controllers.SiteController
     * @extends Jii.base.Controller
     */
    Jii.defineClass('app.controllers.SiteController', /** @lends app.controllers.SiteController.prototype */{
    
        __extends: Jii.base.Controller,
    
        /**
         *
         * @param {Jii.base.Context} context
         * @param {Jii.httpServer.Request} context.request
         * @param {Jii.httpServer.Response} context.response
         */
        actionIndex: function(context) {
            context.response.data = this.render('index');
            context.response.send();
        }
    
    });
    

    Сущности



    Jii приложения организованы согласно шаблону проектирования модель-представление-поведение (MVC) и имеют следующие сущности:
    • приложения: это глобально доступные объекты, которые осуществляют корректную работу различных компонентов приложения и их координацию для обработки запроса;
    • компоненты приложения: это объекты, зарегистрированные в приложении и предоставляющие различные возможности;
    • компоненты запроса: это объекты, зарегистрированные в контексте запроса и предоставляющие различные возможности для обработки текущего запроса;
    • модули: это самодостаточные пакеты, которые включают в себя полностью все средства для MVC. Приложение может быть организованно с помощью нескольких модулей;

    Примеры их использовать можно увидеть в демо.

    Приложения


    Приложения это объекты, которые управляют всей структурой и жизненным циклом прикладной системы Jii. Обычно на один воркер (процесс) Node.js приходит один экземпляр приложения Jii, который доступен через Jii.app.
    Когда входной скрипт создаёт приложение, он загрузит конфигурацию и применит её к приложению, например:

    var Jii = require('jii');
    
    // загрузка конфигурации приложения
    var config = {
        application: {
            basePath: __dirname,
            components: {
                http: {
                    className: 'Jii.httpServer.HttpServer'
                }
            }
        },
        context: {
            components: {
                request: {
                    baseUrl: '/myapp'
                }
            }
        }
    };
    
    // создание объекта приложения и его конфигурирование
    Jii.createWebApplication(config);
    

    Важное отличие от Yii в том, что конфигурация делится на две части — конфигурация приложения (секция application) и конфигурацию контекста (запроса) (секция context). Конфигурация приложения создаёт и настраивает компоненты, модули и конфигурирует само приложение (Jii.app) — всё это происходит при запуске воркера. В свою очередь, конфигурация контекста создаёт и настраивает компоненты при каждом вызове экшена — http запросе, вызове консольной команды и т.п. Созданные компоненты передаются как первый аргумент в метод экшена.

    Из-за того, что конфигурация приложения часто является очень сложной, она выносится в файлы и разбивается на несколько конфигурационных файлов.

    Компоненты приложения


    Приложения хранят множество компонентов приложения, которые предоставляют различные средства для работы приложения. Например, компоненты urlManager ответственен за маршрутизацию веб запросов к нужному контроллеру; компонент db предоставляет средства для работы с базой данных; и т. д.

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

    Jii.app.ComponentID
    

    Встроенные компоненты приложения


    В Jii есть несколько встроенных компонентов приложения, с фиксированными ID и конфигурациями по умолчанию.

    Ниже представлен список встроенных компонентов приложения. Вы можете конфигурировать их также как и другие компоненты приложения. Когда вы конфигурируете встроенный компонент приложения и не указываете класс этого компонента, то значение по умолчанию будет использовано.
    • db, Jii.sql.BaseConnection: представляет собой соединение с базой данных, через которое вы можете выполнять запросы. Обратите внимание, что когда вы конфигурируете данный компонент, вы должны указать класс компонента также как и остальные необходимые параметры.
    • urlManager, Jii.urlManager.UrlManager: используется для разбора и создания URL;
    • assetManager, Jii.assets.AssetManager: используется для управления и опубликования ресурсов приложения;
    • view, Jii.view.View: используется для отображения представлений.

    Компоненты контекста


    Набор компонентов контекста зависит от того, где он применяется. Самый распространённый вариант — это HTTP запрос пользователя, для него мы и рассмотрим встроенный набор компонентов.

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

        actionIndex: function(context) {
            context.ComponentID
        }
    

    Встроенные компоненты запроса


    Ниже представлен список встроенных компонентов запроса. Вы можете конфигурировать их также как и другие компоненты в секции context в конфигурационном файле.

    • response, Jii.base.Response: представляет собой данные от сервера, которые будет направлены пользователю;
    • request, Jii.base.Request: представляет собой запрос, полученный от конечных пользователей;
    • user, Jii.user.WebUser: представляет собой информацию аутентифицированного пользователя;

    Контроллеры


    Контроллеры являются частью MVC архитектуры. Это объекты классов, унаследованных от Jii.base.Controller и отвечающие за обработку запроса и генерирование ответа. В сущности, при обработки запроса HTTP сервером (Jii.httpServer.HttpServer), контроллеры проанализируют входные данные, передадут их
    в модели, вставят результаты модели в [представления](structure-views), и в конечном итоге сгенерируют исходящие ответы.

    Действия (Actions)


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

    Следующий пример показывает post контроллер с двумя действиями: view и create:

    /**
     * @class app.controllers.PostController
     * @extends Jii.base.Controller
     */
    Jii.defineClass('app.controllers.PostController', /** @lends app.controllers.PostController.prototype */{
    
        __extends: Jii.base.Controller,
    
        actionView: function(context) {
            var id = context.request.get('id');
    
            return app.models.Post.findOne(id).then(function(model) {
                if (model === null) {
                    context.response.setStatusCode(404);
                    context.response.send();
                    return;
                }
    
                context.response.data = this.render('view', {
                    model: model
                });
                context.response.send();
            });
        },
    
        actionCreate: function(context) {
            var model = new app.models.Post();
    
    		Jii.when.resolve().then(function() {
    			// Save user
    			if (context.request.isPost()) {
    				model.setAttributes(context.request.post());
    				return model.save();
    			}
    
    			return false;
    		}).then(function(isSuccess) {
                if (isSuccess) {
                    context.request.redirect(['view', {id: model.get('id')}])
                } else {
                    context.response.data = this.render('create', {
                        model: model
                    });
                    context.response.send();
                }
    		});
        }
    
    });
    

    В действии view (определенном методом actionView()), код сначала загружает модель согласно запрошенному ID модели; Если модель успешно загружена, то код отобразит ее с помощью представления под названием view.

    В действии create (определенном методом actionCreate()), код аналогичен. Он сначала пытается загрузить модель с помощью данных из запроса и сохранить модель. Если все прошло успешно, то код перенаправляет браузер на действие view с ID только что созданной модели. В противном случае он отобразит представление create, через которое пользователь может заполнить нужные данные.

    Маршруты (Routes)


    Конечные пользователи обращаются к действиям через так называемые *маршруты*. Маршрут — это строка, состоящая из следующих частей:
    • ID модуля: он существует, только если контроллер принадлежит не приложению, а [модулю](structure-modules);
    • ID контроллера: строка, которая уникально идентифицирует контроллер среди всех других контроллеров одного и того же приложения (или одного и того же модуля, если контроллер принадлежит модулю);
    • ID действия: строка, которая уникально идентифицирует действие среди всех других действия одного и того же контроллера.

    Маршруты могут иметь следующий формат:

    ControllerID/ActionID
    

    или следующий формат, если контроллер принадлежит модулю:

    ModuleID/ControllerID/ActionID
    

    Создание действий


    Создание действий не представляет сложностей также как и объявление так называемых *методов действий* в классе контроллера. Метод действия это метод, имя которого начинается со слова action. Возвращаемое значение метода действия представляет собой ответные данные, которые будут высланы конечному пользователю. Приведенный ниже код определяет два действия index и hello-world:

    /**
     * @class app.controllers.SiteController
     * @extends Jii.base.Controller
     */
    Jii.defineClass('app.controllers.SiteController', /** @lends app.controllers.SiteController.prototype */{
    
        __extends: Jii.base.Controller,
    
        actionIndex: function(context) {
            context.response.data = this.render('index');
            context.response.send();
        },
    
        actionHelloWorld: function(context) {
            context.response.data = 'Hello World';
            context.response.send();
        }
    
    });
    

    Действия-классы


    Действия могут определятся в качестве классов, унаследованных от Jii.base.Action или его потомков.

    Для использования такого действия, вы должны указать его с помощью переопределения метода Jii.base.Controller.actions() в вашем классе контроллера, следующим образом:

    actions: function() {
        return {
            // объявляет "error" действие с помощью названия класса
            error: 'app.actions.ErrorAction',
    
            // объявляет "view" действие с помощью конфигурационного объекта
            view: {
                className: 'app.actions.ViewAction',
                viewPrefix: ''
            }
        };
    }
    

    Как вы можете видеть, метод actions() должен вернуть объект, ключами которого являются ID действий, а значениями — соответствующие названия класса действия или [конфигурация](concept-configurations). В отличие от встроенных действий, ID отдельных действий могут содержать произвольные символы, до тех пор пока они определены в методе actions().

    Для создания отдельного действия, вы должны наследоваться от класса Jii.base.Action или его потомков, и реализовать публичный метод run(). Роль метода run() аналогична другим методам действий. Например,

    /**
     * @class app.components.HelloWorldAction
     * @extends Jii.base.Action
     */
    Jii.defineClass('app.components.HelloWorldAction', /** @lends app.components.HelloWorldAction.prototype */{
    
        __extends: Jii.base.Action,
    
        run: function(context) {
            context.response.data = 'Hello World';
            context.response.send();
        }
    
    });
    

    Модули


    Модули — это самодостаточные программные блоки, состоящие из моделей, представлений, контроллеров и других вспомогательных компонентов. При установке модулей в приложение, конечный пользователь получает доступ к их
    контроллерам. По этой причине модули часто рассматриваются как миниатюрные приложения. В отличии от приложений, модули нельзя создавать отдельно, они должны находиться внутри приложений.

    Создание модулей


    Модуль помещается в директорию, которая называется базовым путем модуля (Jii.base.Module.basePath). Так же как и в директории приложения, в этой директории существуют поддиректории controllers, models, views и другие, в которых размещаются контроллеры, модели, представления и другие элементы. В следующем примере показано примерное содержимое модуля:

    modules/
        forum/
            Module.js                   файл класса модуля
            controllers/                содержит файлы классов контроллеров
                DefaultController.js    файл класса контроллера по умолчанию
            models/                     содержит файлы классов моделей
            views/                      содержит файлы представлений контроллеров и шаблонов
                layouts/                содержит файлы представлений шаблонов
                default/                содержит файлы представления контроллера DefaultController
                    index.ejs           файл основного представления
    

    Классы модулей


    Каждый модуль объявляется с помощью уникального класса, который наследуется от Jii.base.Module. Этот класс должен быть помещен в корне базового пути модуля. Во время запуска приложения (воркера) будет
    создан один экземпляр соответствующего класса модуля. Как и экземпляры приложения, экземпляры модулей нужны, чтобы код модулей мог получить общий доступ к данным и компонентам.

    Приведем пример того, как может выглядеть класс модуля:

    /**
     * @class app.modules.forum
     * @extends Jii.base.Module
     */
    Jii.defineClass('app.modules.forum.Module', /** @lends app.modules.forum.Module.prototype */{
    
        __extends: Jii.base.Module,
    
        init: function(context) {
            this.params.foo = 'bar';
    
            return this.__super();
        }
    
    });
    

    Контроллеры в модулях


    При создании контроллеров модуля принято помещать классы контроллеров в подпространство controllers пространства имен класса модуля. Это также подразумевает, что файлы классов контроллеров должны располагаться в директории controllers базового пути модуля. Например, чтобы описать контроллер post в модуле forum из предыдущего примера, класс контроллера объявляется следующим образом:

    var Jii = require('jii');
    
    /**
     * @class app.modules.forum.controllers.PostController
     * @extends Jii.base.Controller
     */
    Jii.defineClass('app.modules.forum.controllers.PostController', /** @lends app.modules.forum.controllers.PostController.prototype */{
    
    	__extends: Jii.base.Controller,
    
        // ...
    
    });
    

    Изменить пространство имен классов контроллеров можно задав свойство Jii.base.Module.controllerNamespace. Если какие-либо контроллеры выпадают из этого пространства имен, доступ к ним можно осуществить, настроив свойство Jii.base.Module.controllerMap, аналогично тому, как это делается в приложении.

    Использование модулей


    Чтобы задействовать модуль в приложении, достаточно включить его в свойство Jii.base.Application.modules в конфигурации приложения. Следующий код в конфигурации приложения задействует модуль forum:

    var config = {
        application: {
            // ...
            modules: {
                forum: {
                    className: 'app.modules.forum.Module',
                    // ... другие настройки модуля ...
                }
            }
        },
        context: {
            // ...
        }
    };
    

    Свойству Jii.base.Application.modules присваивается объект, содержащий конфигурацию модуля. Каждый ключ объекта представляет собой *идентификатор модуля*, который однозначно определяет модуль среди других модулей приложения, а соответствующий объект — это конфигурация для создания модуля.

    Доступ к модулям


    Доступ к экземпляру модуля можно получить следующим способом:

    var module = Jii.app.getModule('forum');
    

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

    var maxPostCount = module.params.maxPostCount;
    

    В заключении



    Ниже я предлагаю опрос о формате кода Jii. Если выбираете не JavaScript-формат, то укажите в комментариях как бы вы решали проблемы, описанные в разделе «Почему не ES6 classes (и не CoffeeScript/TypeScript)?» в этой статье.
    Напомню, Jii — опенсорсный проект, поэтому я буду очень рад, если кто-то присоединится к его разработке. Пишите на affka@affka.ru.

    Сайт фреймворка — jiiframework.ru
    GitHub — https://github.com/jiisoft
    Обсуждение фич проходит на гитхабе

    Понравилось? Поставь звезду на гитхабе!

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

    Какой формат создания классов нужен Jii?
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 73
      +21
      Поздравляю! Вам удалось-таки вернуться в 2007 год!
        –3
        Какая жесть. Зачем пытаться привести один язык к другому? Лучше использовать Yii (или Rails, от которого Yii и пошел) и радоваться жизни.
          +2
          Какая же жесть когда люди даже вникнуть не пытаются.
          Jii проектируется с учётом того, что он должен работать везде где можно — браузер, сервер, phonegap, node-webkit и т.п.

          Это не перевод одного языка в дорогому, а заимствование архитектуры и подход фреймворка Yii для реализации приложений на js на фронте, беке в едином стиле.
          Конечно сомнительно дальнейшее развитие проекта сообществом, и в целом его использование, но идея прикольная :)
            0
            Я имел ввиду, что есть другие фреймворки, которые были разработаны учитывая особенности JS. И, по моему скромному мнению, использовать их будет логичнее.
              0
              заимствование архитектуры и подход фреймворка Yii для реализации приложений на js на фронте
              Вот уж чего точно не стоит делать — там другие проблемы, нужны другие подходы. Да и решений (самых разных) хватает.
              +2
              Когда нужно сделать какое-либо реалтайм приложение, с комет-сервером или демонами — то PHP уже лучше не использовать. Да, можно использовать множество других языков программирования буть то Ruby/Python/Go/… Но если есть знания только JavaScript (а они сейчас у большинства должны быть, frontend никто не отменял), то можно начать использовать Node.js, а когда есть еще и похожий на ранее используемый в PHP фреймворк — это большой плюс, в этом основная идея.
              И если Вы владеете хорошо другим ЯП, который решает данные задачи — то скорее всего и не стоит переходить на Node.js с Jii, статья не для вас просто.
                0
                >а они сейчас у большинства должны быть

                У большинства кого, простите? Тех кто занимается frontend? Ну да, логично наверное. Но не все же им занимаются и даже не большинство
                  +2
                  Да, я про frontend. Мне кажется любому веб-разработчику приходилось хоть немного, но сталкиваться с JavaScript.
                    0
                    и достаточно много людей, которые его ненавидят. Я вот, к примеру, лучше напишу на Go (с которым не имею никакого опыта), чем на node.js, хотя во фронтенде многолетний опыт как fullstack программист
                      0
                      А я наоборот, открыл для себя ноду не так давно, и меня буквально прет на ней что-то делать. Особенно доставляет асинхронность, заставляет думать.
                    –1
                    По вашему бекенд разработчиков на js не бывает? nodejs под современные задачи куда более лучше ложится нежели любой другой язык(тул).
                    А фронт сейчас если не больше, то как минимум ровня по значимости в проекте. Так как его стеки юзаются не только в браузере и сейчас все же уже не те, требования как раньше. Сейчас все хотят себе spa и прочие приложухи.
                      0
                      >По вашему бекенд разработчиков на js не бывает?

                      Бывает конечно, но в оригинале написано именно «у большинства». Я позволю себе даже не бегая за реальными цифрами сделать утверждение, что большинство программистов (даже не разделяя фронт и бэк) — не js программисты и многие с ним если сталкивались, то разве что на уровне какого-нибудь простого скрипта или вообще добавление небольшого куска jquery на страницу.

                      По этому мне утверждение о том, что большинство почему-то должно знать и уметь js показалось странным.
                    0
                    Да, спасибо. В таком свете это кажется вполне логичным. Но все-таки :)
                  0
                  Идея отличная! Обязательно попробую его в своих проектах.
                    +8
                    Транслирование ES6 в более ранние редакции стандарта можно сделать через Babel.
                    При разработке вы можете использовать node-babel, а перед публикацией пакета в npm выполнять соответствующий таск в секции scripts.prepublish. Пример по ссылке.

                    В es6 нет неймспейсов, а они нужны для повторения фич Yii. Их можно имплементировать через модули, но это будет костыль. Менять один костыль на другой — нет смысла.

                    В ES5 тоже нет специального синтаксиса неймспейсов, и что? ES6 есть модули — используйте их!

                    В ES6 захочется использовать геттеры и сеттеры, но они не поддерживаются старыми браузерами, как говорилось выше

                    Геттеры и сеттеры появились еще в ES5, что изменилось?

                    Многие разработчики не знают формата es6/coffeescript/typescript и это будет дополнительный порог вхождения

                    Надуманно.

                    Сложность работы с кодом разных форматов (ES5 и ES6). Не всегда есть возможность в существующем проекте поменять весь код на es6, а наследовать es6 классы все равно нужно, и все равно прийдется использовать Jii.defineClass() для создания классов — костыль не уходит.

                    Не придется.
                      –6
                      > Надуманно.
                      Нет
                        +1
                        Если они не знают чего-то из вышеперечисленного они просто не знают JS
                      +4
                      Сложность работы с кодом разных форматов (ES5 и ES6).

                      Вы так говорите как будто это разные языки а не расширение существующего. И вы уверены что уже не используете не ведая о том некоторый ES6 плюшки? А если таки не используете то уверены ли что хорошо делаете?

                      JavaScript фреймворк с архитектурой от Yii 2

                      А тут пожалуй кроется главная проблема.
                        +4
                        > JavaScript фреймворк с архитектурой от Yii 2

                        Но зачем???
                          +5
                          Ну нравится человеку — пусть пишет :)
                            +1
                            Ребят, я не один такой, кому пришла в голову такая идея. Вы просто другого мнения, проходите мимо :)
                              0
                              Согласен. У меня к проекту только один вопрос — даже Yii2 еще очень сырой, хотя я его и использую, просто потому что первый всё равно уходит. А с JII большой вопрос — будет ли когда-то достаточно развитый код, и достаточная экосистема, чтобы стоило им пользоваться. А так — была бы отличная идея.
                                0
                                Yii2 уже не сырой, мы его в нескольких проектах в продакшене используем и багов критичных не замечал. Jii еще только начал развиваться, но у него большое будущее. Я жду когда появится какой-нить заказ (проект) большой, на котором можно будет его освоить, тогда и баги всплывут и поддерживать хочешь или нет — прийдется.
                                  +1
                                  Я тоже его использую. И тоже не вижу критичных багов. Но по степени его развитости он сильно уступает первому.
                                  Документация слабовата, пул расширений еще недостаточно развит, даже просто ответов на разные ситуации в гугле меньше… Всё это в разы меньше. Меня устраивает уровень развития экосистемы первого. Количество специалистов, документации, документации сторонних разработчиков, кучи примеров, кучи расширений и т.п. Но новые проекты на нем писать нерационально. Поэтому приходится начинать работать на втором, мирясь с недостатками и надеясь что экосистема быстро доростет.
                                  У вас же стадия в разы хуже. Ничего личного, но одному такую задачу не поднять. Я тоже когда-то думал, что необходимость поддержки большого проекта поможет сохранить фреймворк. Закончилось переездом проекта под юии2)
                                  Пока-что было интересно почитать, будем надеяться что пару человек в команду к вам присоединится, а тогда уже может и лавина пойдет. Но тут или выгорит или не выгорит…
                                    +2
                                    Один человек уже присоединился, надеюсь не последний :)
                                –1
                                Но ведь вопрос действительно интересный!
                                Почему, к примеру, не Jymfony или Jaravel, или Jend в конце концов?)
                                Есть какое-то логическое объяснение, кроме «вы другого мнения, проходите мимо»?
                                  +2
                                  Просто потому что я хорошо знал Yii. Jii вырос не из идеи «клонировать какой-нить фреймворк», а из потребности сделать какую-то архитектуру в одном из проектов, и писалось нечто похожее на Yii и только потом это все выросло в отдельный проект и переписано с нуля. Немного истории тут.
                              +1
                              Скорее почему. Когда люди меняют один язык на другой, они стараются писать старыми методами в новом/другом языке. Я тоже так делал, но быстро прошло.
                                0
                                Проходит, когда есть что-то взамен. Я вот не видел в Node.js нормального Query Builder и Active Record (во всяком случае в то время, когда его писал, сейчас — не знаю, подскажите), которые можно было бы сравнить по функционалу с Yii.
                                Yii ведь тоже много чего взял с других фреймворков и других языков программирования, но от этого ведь он хуже не стал :)
                                  +2
                                  У каждого свои понятия «нормальности». Я пользуюсь mongoose, как и многие другие JS разработчики. Некоторые хвалят Sequelize.
                                    +1
                                    Да, Sequelize — хорошая альтернатива. Раньше тоже его видел, но он был не такой богатый вроде.
                                    Ну а mongoose — это только монгодб, иногда нужны реляционные БД.
                                      0
                                      Sequelize хорошая штука, но это не QueryBuilder. Если нужно мало-мальски не тривиальный запрос сделать, то он уже становится бессильным. Приходится для этих целей использовать squel.
                                        +4
                                        У Вас из ORM только первая ссылка, остальное — клиенты БД (драйвера).
                                          0
                                          Признаюсь, было лень искать именно ORM, гуглил исключительно по названию баз данных, поэтому исправляюсь:

                                          www.npmjs.com/package/orm (MySQL & MariaDB, PostgreSQL, Amazon Redshift, SQLite, MongoDB)
                                          www.npmjs.com/package/oracle-orm (Oracle)
                                          bookshelfjs.org (PostgreSQL, MySQL & SQLite3)
                                          docs.sequelizejs.com/en/latest (PostgreSQL, MySQL, MariaDB, SQLite & MSSQL)

                                          Чем ваше решение лучше?
                                            0
                                            bookshelf ранее не видел, про sequelizejs уже писал.
                                            Да оно и не обязано быть на голову выше, альтернатива — это ж ведь всегда хорошо. :)
                                            Просто кому-то (как, например мне) будет легче использовать ORM с уже ранее известным API.

                                            bookshelf, кстати, даже чем-то схож с Jii
                                              +3
                                              Совместимость со знакомым АПИ это большой плюс. Очень большой.
                                              Недавно обсуждали в одном проекте переход на другой фреймворк.
                                              Предложенный сеньором набор технологий был бы идеальным. Ситуация в проекте позволяет менять технологию ибо в существующих подпроектах или перенос на другой фремворк или глобальный рефакторинг или такая стадия разработки что легко можно поменять.
                                              Идею мы завернули чисто потому что хоть разрабов можно подтянуть на нужный пул технологий, но это требует времени, и дальнейшая поддержка будет дорогая. Новые спецы дороги, хороший спец по нужным технологиям у нас только один, в случае его уходя будут проблемы… в общем завернули мы этот план. На юии2 я могу сесть и писать сам. Даже менеджер наш кое-что может сделать в юии2, потому как в свое время я его начинал учить на верстальщика, и CRUD-приложения он говнокодил под юии2 исправно…
                                              А вот если бы Jii уже была бы стабильной и с экосистемой и предложение перехода было бы на него, то такой вопрос бы даже не вставал бы — перешли бы не задумываясь. И не потому что юии2 идеальный фреймворк. Нет. Просто он ХОРОШИЙ и ЗНАКОМЫЙ. Всё.
                                                0
                                                Именно в этом и идея фреймворка, спасибо за понимание :)
                                                  –2
                                                  Звучит как «Мы не хотим учиться новым технологиям». Если так, то зачем их использовать?
                                                  0
                                                  Есть ещё классный www.npmjs.com/package/waterline — у него фишка что кроме обычных SQL баз данных, поддерживает ещё и MongoDB.
                                                    0
                                                    В Jii в будущем тоже планируется, по аналогии с yii2-mongodb, может быть даже кто-нить возмется реализовывать
                                                      0
                                                      Мне Waterline не понравился багами.
                                                        0
                                                        Это было недавно? Можете вспомнить о каких багах идет речь?
                                                          0
                                                          6 месяцев назад. В связке с sails.js. При указании схемы бд в модели с опцией safe = true && strict = true waterline пропускал неправильные (invalid) документы. Что противоречит «маркетингу» модуля.
                                                            0
                                                            Спасибо за информацию. Мы активно используем sails.js и пока с такой проблемой ещё не сталкивались, но будем готовы :)
                                        0
                                        Вы бы ещё “jsNuke” на яваскрипте запилили с соответствующей архитектурой phpNuke'а.
                                          +2
                                          Juke
                                          +5
                                          phpNuke так страшен, что даже шутить про него опасно? (:
                                            +2
                                            Я уже понял свою ошибку.
                                              +1
                                              WIKI:
                                              Написана на PHP с использованием СУБД MySQL (последние версии (6.5 и позднее) поддерживают также соединения с такими базами данных, как PostgreSQL, Microsoft SQL Server, MS Access, Oracle, DB2, SQLite). Данная возможность появилась после подключения популярного форума phpBB к php-Nuke в виде модуля.

                                              Мне уже страшно стало o_O
                                            –1
                                            Да сколько моно уже плодить эти JS фреймворки.
                                              +2
                                              Как тесно в японском языке соседствуют мастурбация, дед и диизопропиловые эфиры…
                                              0
                                              Чем обусловлен выбор when, а не github.com/petkaantonov/bluebird?
                                                +1
                                                Правильный вопрос зачем вообще промисы и уж тем более полифилы, если сегодня они уже нативно поддерживаются.
                                                  0
                                                  Имплементацию производительности выбирал исходя из производительности. Промисы нативно далеко не везде есть, when их реализует по спецификации es6 — поэтому когда в node появятся промисы — будут они использоваться
                                                    0
                                                    Как вы меряли производительность? ;)
                                                        –1
                                                        Ок скажу иначе: практически все микробенчмарки для JS делаются неправильно.
                                                          0
                                                          т.е. вы можете сделать правильный бенчмарк и сказать кто лучше?
                                                            –3
                                                            Нет и дело это бессмысленное.
                                                        0
                                                        Конктерно я — никак, я нашел где-то результаты тестирования (уже не помню где), где when был один из передовых. Из передовых выбрал наиболее понятный и им оказался when.
                                                        +2
                                                        К сведению, они уже появились и доступны без --harmony флага.
                                                          +1
                                                          Ух ты, точно. Спасибо! Как-то я это пропустил… Значит будет изменено в сторону нативных промисов
                                                        0
                                                        «V8 native promises are freakishly slow. If you require any type of performance while using Promises then I'd recommend bluebird.» написал один из основных контрибьюторов Node.js ;) github.com/joyent/node/issues/14384
                                                          0
                                                          главное чтоб один и тот же стандарт имплементировали — поменять то не долго :)
                                                      +1
                                                      Юзаю на серьезном проекте. Штука что нада. И шторм понимает неймспейсы. Советую!
                                                        0
                                                        Спасибо за отзыв! :) Скоро браузерная версия + комет сервер в релиз пойдет :) Уже документацию и пример пишу.
                                                        0
                                                        Спецы по es6, вам слово — toster.ru/q/276621 :)

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое