Я активно работаю над апдейтом Netzke, который будет работать с последней доступной версией Ext JS. Промежуточный вариант можно найти в ветке ext42 — его должно быть достаточно для данного тюториала.
Насчет линков на скачивание Ext JS и иконок — полностью согласен, исправлю.
Я имел в виду механизм кэширования встроенный в Netzke. Работает он так: когда я хочу динамически подгрузить, например, грид — для этого нужен Ext JS код самого класса компонента, плюс конфигурация для создания его образца (например, где будет указано, какие колонки должны быть отображены). И то, и другое, подгружается с сервера. JS эвалюируется, после чего класс оказывается объявлен в браузере. В следующий раз, когда нужен грид (по-другому сконфигурированный — например, привязанный к другой модели), с сервера загружается уже только конфигурация, потому что повторно эвалюировать сам класс необходимости нет.
Согласен с оценкой того, как выглядит код. В этом смысле Netzke довольно-таки облегчает жизнь:
1) Netzke-компонент, будучи однажды написанным (для чего наверняка понадобится знание Ext JS), после этого встраивается в Рельсы (или другие компоненты), путем использования преимущественно Руби. Т.е. JS «заворачивается» в компоненту, и основным ее интерфейсом становится ее Руби класс (в Руби происходит, в частности, конфигурация клиентской части компоненты, и код читается достаточно просто). Т.е. необходимость «связываться» с Ext JS значительно снижается, соответственно процент экспертов в Ext JS в команде разработчиков может быть также снижен.
3) (Тут не именно о качестве кода, но имеет отношение к нему) Разработка, отладка и автоматическое тестирование отдельного компонента, выполняющего конкретную функцию в приложении — намного более приятный процесс, чем отладка монструозного монолитного Ext JS приложения. Конечно, при умелом подходе и Ext JS код можно писать модульно, но преимущество компонента Netzke в том, что он включает в себя и серверную часть кода.
Насчет оценки скорости сложно как-то прокомментировать, потому что скорость сильно зависит и от качества кода тоже, от выбранных подходов в решении разных мини-задач (и в том числе и от серверной части тоже). Если бы было более определенное описание какой-то проблемы с быстродействием Ext JS — тогда было бы возможно ее обсудить.
Грид — это всего лишь пример компонента, и, конечно, в него совершенно неуместно совать бизнес-процессы, не связанные с обработкой конкретной модели.
А вот если создать комплексную компоненту, которую условно назовем Application, которая будет содержать в себе «самый верх» бизнес-логики приложения (например, загрузка других компонент, сравнимо с Views), всевозможные меню, компонент дерево-эксплорер (к примеру), и любое количество других (возможно, также комплексных) компонент, в каждом из которых реализован свой кусок логики приложения — вот тогда и получится гибкое, стройное приложение, для упрощения создания которого я и написал Netzke.
Другими словами: каждый компонент в приложении должен отвечать за четко определенный набор задач, как-можно более изолированный от остального приложения. В этом смысл компонентного подхода к созданию приложений — и это то, чего мне не хватало в Рельсах (повторюсь: когда вопрос касался сложных одностраничных приложений).
Теперь понятнее, и в этом случае мы на одной волне, просто нашли разные подходы, которые было бы интересно сравнить в деталях — с удовольствием бы почитал статью.
Не только «страшненькое», это даже не главное. Здесь у нас сортировка, pagination, поиск, редактирование inline, и прочее. И — самое главное — нет ни сгенерированного View, ни Controller, что очень критично для приложений с сотнями моделей (подробнее про это в моих комментариях ниже).
Похоже, вы нашли вполне интересный и работающий способ отображения форм для моделей.
Против кодогенераторов я выступаю только по той причине, что когда в приложении сотни моделей, кодогенераторы приводят к огромному количеству дуплицированного кода. Чтобы добавить/улучшить фичу во всех 100 гридах в приложении на Нецке, необходимо просто подправить Netzke::Basepack::Grid (или унаследованный от него свой грид, служащий базой для всех остальных гридов). А в случае со сгенерированным кодом — исправлять придется в 100 местах.
возможность открыть несколько пунктов меню одновременно (например в отдельных табах), их сохранение между перезагрузками страницы, и stateful для гридов
Именно этого Netzke позволяет избежать. Конечно, создания моделей не избежишь, по-крайней мере в Рельсах, но Views и Controllers становятся не нужны, что освобождает нас от огромного количества не DRY кода. Взгляните, сколько кода нам понадобилось, чтобы создать грид-компонент, который работает с данной моделью — ок 14 строк. Ни одного View или Controller. Как это возможно? Благодаря тому, что вся View/Controller-логика — внутри Netzke::Basepack::Grid. И все, что нам нужно — унаследовать от нее (легко ли унаследовать View в Рельсах?..) и нужным образом сконфигурировать. Вся сортировка, поиск, автоматическое определение полей, даже конфигурация колонок налету (что не попало в этот пост) и т.д. — все это внутри Netzke::Basepack::Grid, и в этом сила компонентного подхода.
Это очень критично для сложных приложений, использующих сотни моделей (смотрите, например, мою заявку на EuRuKo — к сожалению, на английском).
Что касается того, что какие-то части приложения подгружаются динамически — это вовсе не обязательно с Нецке и остается на усмотрении разработчика. Когда в приложении, к примеру, сотни моделей (это не преувеличение, я работал с таким), «просто» сгенерировать Ext JS приложение целиком — это получилось бы очень, очень много кода, загрузка (и выполнение в браузере) которого заняла бы слишком много времени. Нецке же позволяет разработчику решать, что загружается сразу, а что позже, по запросу пользователя. Те же формы — они не обязаны загружаться с сервера каждый раз, я в одном из комментариев ниже подробнее про это написал.
Нецке разрабатывалась как-раз с расчетом делать быстрые Ext JS-приложения — именно этому способствуют встроенные механизмы кэширования JS классов, динамическая подгрузка кода компонентов, мультиплексирование запросов на сервер от нескольких компонент (с помощью Ext.Direct) и др.
Да, это один из воможных вариантов. Я выбрал сделать чуть по-другому: показывать маску Loading в самом гриде, пока загружается и код для формы (только первый раз, после чего кэшируется), и то, что в ней нужно отобразить. Если скорость доступа большая, то маску действительно можно и не увидеть.
Иногда редактирование в форме не нужно, и чтобы не загружать сразу лишний JS код для формы, его подгрузка сделана динамической. Кстати, JS для класса формы подгружается только первый раз, после чего кэшируется, и с сервера грузится уже только собственно раскладка полей. Это дает нам гибкость в принятии решения на сервере, какие именно поля отображать в форме, что иногда может меняться прямо в процессе работы приложения. И, конечно, поля в форме и колонки в гриде могут отличаться (часто так и происходит) — это конфигурируется в классе грида.
Однако, запрос на сервер при нажатии Add in form воможно отключить, если указать, что форма должна загружаться eagerly вместе с гридом. Это конфигурируется тоже.
Как и у некоторых других отписавшихся, в период знакомства с Ext JS и написания первых приложений, я был не раз близок к отчаянию из-за той самой крутой кривой обучения, непонятных ошибках, новых для меня концептов в их архитектуре. Но, действительно, с получением опыта, в голове у меня все более-менее разложилось по полочкам, и на уровне пользователя Ext JS (в противопоставление создателю новых компонент) я себя чувствую более чем комфортно. Но мне сильно не хотелось бы влезать на уровень рендеринга их компонент, HTML & CSS — считаю, это требует уже значительно больших знаний, чем есть у меня.
Что меня лично начало смущать в работе после того, как я достаточно свыкся с Ext JS, это как красиво привязывать Ext JS к серверной части. REST — это круто, но… даже для него нужна куча серверного кода, в моем случае контроллеров Ruby on Rails. Просто представьте себе, что нужно написать приложение, обслуживающее сотни таблиц в базе данных. Для каждой из них писать контроллер? Или вынести общий код в модули, а потом подключать? Но тогда этот код нужно сделать сильно умным — чтобы его можно было конфигурировать под специфические требования, связанные с каждой моделью данных. А потом становится нужна authorization, несколько гридов на одной странице, динамическая подгрузка Ext JS компоненты и т.д…. В общем, через год после работы с Ext JS и Рельсами, я решил применить весь свой полученный опыт к написанию расширения для Рельс, которое позволяло бы писать *компоненты*, которые — внимание! — содержали бы в себе каким-то чудесным образом и клиентскую, и серверную часть. Имея такие компоненты, их можно было бы расширять с помощью ООП, комбинировать (англ: nest) в новые компоненты, разрабатывать и тестировать изолированно от остального приложения, динамически подгружать и т.д. Так родился Netzke.
Как он поможет тем, кто жалуется на крутую кривую обучения? Он позволяет отодвинуть необходимость изучения Ext JS немного вперед в будущее (ну или растянуть его во времени, сделать менее критичным), и позволять составлять достаточно сложные приложения, пользуясь в основном Руби. Это достигается тем, что JavaScript код для компонент Нецке — «скрыт» внутри компоненты, и знать о нем даже не обязательно, пока не начинаешь писать новые компоненты.
Если интересно — вот пример приложения (это всего лишь демо, конечно) которое буквально можно сделать за 3-4 часа, пользуясь готовыми компонентами: yanit.heroku.com. Обратите внимание на весь тот богатый набор операций, который поддерживается *каждой* из таблиц.
Вот еще немного устаревший (Netzke обновился с тех пор), но вызвавший позитивные отзывы пост с хабра: habrahabr.ru/post/133935/
Если необходимо что-то намного большее, чем просто CRUD, и интересует инструмент для создания полнофункциональных одностраничных много-модельных приложений на основе Ruby on Rails — взгляните на Netzke. Помимо уже готовой таблицы, которая кроме CRUD поддерживает поиск, фильтр, динамическое перемещение колонок, и т.д. — Netzke предоставляет также все инструменты для того, чтобы нестить уже готовые компоненты внутри других компонент, наследовать компоненты путем ООП, а также динамически подгружать компоненты (что в случае с одностраничными приложениями, использующими сотни таблиц, очень и очень желательно), и многое другое.
Вот демо-приложение на Netzke, на создание которого ушло всего несколько часов: http://yanit.heroku.com
Здесь линк на статью на Хабре, в которой описывается, как создать CRUD приложение с Netzke всего за несколько минут: http://habrahabr.ru/post/133935/
Я активно работаю над апдейтом Netzke, который будет работать с последней доступной версией Ext JS. Промежуточный вариант можно найти в ветке ext42 — его должно быть достаточно для данного тюториала.
Насчет линков на скачивание Ext JS и иконок — полностью согласен, исправлю.
Кстати, я только что вручную подправил URL, и попал напрямую на страницу для скачивания 4.1.1a: www.sencha.com/products/extjs/download/ext-js-4.1.1. Сейчас добавлю эту ссылку, если Хабр позволит.
1) Netzke-компонент, будучи однажды написанным (для чего наверняка понадобится знание Ext JS), после этого встраивается в Рельсы (или другие компоненты), путем использования преимущественно Руби. Т.е. JS «заворачивается» в компоненту, и основным ее интерфейсом становится ее Руби класс (в Руби происходит, в частности, конфигурация клиентской части компоненты, и код читается достаточно просто). Т.е. необходимость «связываться» с Ext JS значительно снижается, соответственно процент экспертов в Ext JS в команде разработчиков может быть также снижен.
2) Код выглядит более структурировано: github.com/netzke/netzke-core#what-is-a-netzke-component
3) (Тут не именно о качестве кода, но имеет отношение к нему) Разработка, отладка и автоматическое тестирование отдельного компонента, выполняющего конкретную функцию в приложении — намного более приятный процесс, чем отладка монструозного монолитного Ext JS приложения. Конечно, при умелом подходе и Ext JS код можно писать модульно, но преимущество компонента Netzke в том, что он включает в себя и серверную часть кода.
Насчет оценки скорости сложно как-то прокомментировать, потому что скорость сильно зависит и от качества кода тоже, от выбранных подходов в решении разных мини-задач (и в том числе и от серверной части тоже). Если бы было более определенное описание какой-то проблемы с быстродействием Ext JS — тогда было бы возможно ее обсудить.
А вот если создать комплексную компоненту, которую условно назовем Application, которая будет содержать в себе «самый верх» бизнес-логики приложения (например, загрузка других компонент, сравнимо с Views), всевозможные меню, компонент дерево-эксплорер (к примеру), и любое количество других (возможно, также комплексных) компонент, в каждом из которых реализован свой кусок логики приложения — вот тогда и получится гибкое, стройное приложение, для упрощения создания которого я и написал Netzke.
Другими словами: каждый компонент в приложении должен отвечать за четко определенный набор задач, как-можно более изолированный от остального приложения. В этом смысл компонентного подхода к созданию приложений — и это то, чего мне не хватало в Рельсах (повторюсь: когда вопрос касался сложных одностраничных приложений).
Вы, пожалуйста, поосторожнее с такими вопросами! :)
Похоже, вы нашли вполне интересный и работающий способ отображения форм для моделей.
Против кодогенераторов я выступаю только по той причине, что когда в приложении сотни моделей, кодогенераторы приводят к огромному количеству дуплицированного кода. Чтобы добавить/улучшить фичу во всех 100 гридах в приложении на Нецке, необходимо просто подправить
Netzke::Basepack::Grid(или унаследованный от него свой грид, служащий базой для всех остальных гридов). А в случае со сгенерированным кодом — исправлять придется в 100 местах.Да, все это легко делается с Netzke, см, например, netzke-demo.herokuapp.com или yanit.heroku.com.
Именно этого Netzke позволяет избежать. Конечно, создания моделей не избежишь, по-крайней мере в Рельсах, но Views и Controllers становятся не нужны, что освобождает нас от огромного количества не DRY кода. Взгляните, сколько кода нам понадобилось, чтобы создать грид-компонент, который работает с данной моделью — ок 14 строк. Ни одного View или Controller. Как это возможно? Благодаря тому, что вся View/Controller-логика — внутри Netzke::Basepack::Grid. И все, что нам нужно — унаследовать от нее (легко ли унаследовать View в Рельсах?..) и нужным образом сконфигурировать. Вся сортировка, поиск, автоматическое определение полей, даже конфигурация колонок налету (что не попало в этот пост) и т.д. — все это внутри Netzke::Basepack::Grid, и в этом сила компонентного подхода.
Это очень критично для сложных приложений, использующих сотни моделей (смотрите, например, мою заявку на EuRuKo — к сожалению, на английском).
Что касается того, что какие-то части приложения подгружаются динамически — это вовсе не обязательно с Нецке и остается на усмотрении разработчика. Когда в приложении, к примеру, сотни моделей (это не преувеличение, я работал с таким), «просто» сгенерировать Ext JS приложение целиком — это получилось бы очень, очень много кода, загрузка (и выполнение в браузере) которого заняла бы слишком много времени. Нецке же позволяет разработчику решать, что загружается сразу, а что позже, по запросу пользователя. Те же формы — они не обязаны загружаться с сервера каждый раз, я в одном из комментариев ниже подробнее про это написал.
Нецке разрабатывалась как-раз с расчетом делать быстрые Ext JS-приложения — именно этому способствуют встроенные механизмы кэширования JS классов, динамическая подгрузка кода компонентов, мультиплексирование запросов на сервер от нескольких компонент (с помощью Ext.Direct) и др.
Иногда редактирование в форме не нужно, и чтобы не загружать сразу лишний JS код для формы, его подгрузка сделана динамической. Кстати, JS для класса формы подгружается только первый раз, после чего кэшируется, и с сервера грузится уже только собственно раскладка полей. Это дает нам гибкость в принятии решения на сервере, какие именно поля отображать в форме, что иногда может меняться прямо в процессе работы приложения. И, конечно, поля в форме и колонки в гриде могут отличаться (часто так и происходит) — это конфигурируется в классе грида.
Однако, запрос на сервер при нажатии Add in form воможно отключить, если указать, что форма должна загружаться eagerly вместе с гридом. Это конфигурируется тоже.
Что меня лично начало смущать в работе после того, как я достаточно свыкся с Ext JS, это как красиво привязывать Ext JS к серверной части. REST — это круто, но… даже для него нужна куча серверного кода, в моем случае контроллеров Ruby on Rails. Просто представьте себе, что нужно написать приложение, обслуживающее сотни таблиц в базе данных. Для каждой из них писать контроллер? Или вынести общий код в модули, а потом подключать? Но тогда этот код нужно сделать сильно умным — чтобы его можно было конфигурировать под специфические требования, связанные с каждой моделью данных. А потом становится нужна authorization, несколько гридов на одной странице, динамическая подгрузка Ext JS компоненты и т.д…. В общем, через год после работы с Ext JS и Рельсами, я решил применить весь свой полученный опыт к написанию расширения для Рельс, которое позволяло бы писать *компоненты*, которые — внимание! — содержали бы в себе каким-то чудесным образом и клиентскую, и серверную часть. Имея такие компоненты, их можно было бы расширять с помощью ООП, комбинировать (англ: nest) в новые компоненты, разрабатывать и тестировать изолированно от остального приложения, динамически подгружать и т.д. Так родился Netzke.
Как он поможет тем, кто жалуется на крутую кривую обучения? Он позволяет отодвинуть необходимость изучения Ext JS немного вперед в будущее (ну или растянуть его во времени, сделать менее критичным), и позволять составлять достаточно сложные приложения, пользуясь в основном Руби. Это достигается тем, что JavaScript код для компонент Нецке — «скрыт» внутри компоненты, и знать о нем даже не обязательно, пока не начинаешь писать новые компоненты.
Если интересно — вот пример приложения (это всего лишь демо, конечно) которое буквально можно сделать за 3-4 часа, пользуясь готовыми компонентами: yanit.heroku.com. Обратите внимание на весь тот богатый набор операций, который поддерживается *каждой* из таблиц.
Вот еще немного устаревший (Netzke обновился с тех пор), но вызвавший позитивные отзывы пост с хабра:
habrahabr.ru/post/133935/
Надеюсь, кого-то это заинтересует.
Вот демо-приложение на Netzke, на создание которого ушло всего несколько часов: http://yanit.heroku.com
Здесь линк на статью на Хабре, в которой описывается, как создать CRUD приложение с Netzke всего за несколько минут: http://habrahabr.ru/post/133935/
Для front-end'a Netzke использует Sencha Ext JS.
http://writelesscode.com/blog/2012/10/20/extjs-rails-crud-application-in-7-minutes/
Вопрос к опытным хабратьям: есть ли смысл сделать перевод ее на habrahabr'e отдельной статьей? Или стоит просить автора обновить уже существующий?