Не очень понял — а в чем у них идеологическая несовместимость? Если речь идет об одностраничном приложении, то просто клиент с сервером меняются, например, json-ом. А какая у кого идеология не особо важно.
В чем, например, разница — будете вы JQuery-вскими $.ajax () на сервер с рельсами ходить, или экстовым прокси?
А в случае со сгенерированным кодом — исправлять придется в 100 местах.
Ну вот поэтому я и оговорился, что в формате комментария ничерта не понятно )
Там генерится специфичная конфигурация — поля моделей, колонки гридов и всякое такое. Все общее — в базовых классах моделей/контроллеров. При этом в конкретном случае все можно переопределить.
У меня давно назрело желание по этому поводу накатать статью(и), т.к. в рунете не оч много вменяемой инфы по архитектуре экстовых приложений вообще, и Sencha CMD в частности. Да все никак время выбрать не могу. А в комментах, конечно, особо не объяснишь ничего.
Ну я, кажется, понял — тут расчет на быстрое поднятие CRUD-да без необходимости особой переконфигурации/изменения логики приложения.
У меня просто немного другой случай — нужно быстро поднимать морды для работы с данными (например бухгалтерская аналитика, закупки, сметы). Причем у каждого заказчика довольно специфическая логика и бизнес процессы, да и просто, как они это называют — «хотелки», под которые приложения после кодогенераторов нужно нужно подстраивать.
В этом случае отказ от MVC экста сильно чреват — завтра у них будет новая «хотелка» или изменения в бизнес-процессах, и будет армагеддон, если я описывал логику в гридах.
Поэтому поднялся фреймворк приложения — обработка меню, смена языка/тем/ интерфейса, базовые классы, кодогенератор. Приложение генериться, логика/вьюхи подтягиваются, sencha app build — на сервер.
Просто разные сферы применимости.
Ну ок, наверное нет смысла развивать дискуссию по этому поводу, хотя я все же остаюсь приверженцем сборки приложения и используемых компонентов экста в один скрипт )
И, конечно, поля в форме и колонки в гриде могут отличаться (часто так и происходит) — это конфигурируется в классе грида.
Колонки грида и поля формы да, могут.
Я люблю толстые модели и тонкие контроллеры, поэтому поступил следующим образом — в базовом классе модели, от которого наследуются все остальные модели, описал метод getEditForm(). Если для модели установлено свойство editForm (например: editForm: 'app.view.User.edit'), то возвращется ее инстанс с загруженным record, иначе — создается и возвращается дефолтная форма редактирования, в которой присутствуют все поля модели, для которых не установлен признак editable: false.
В итоге получается довольно удобно и гибко — по нажатию кнопки в контроллере достаточно дернуть record.processEdit(), который, в свою очередь, сделает нужные проверки, покажет форму и т.д.
Учитывая что я тоже испорльзую кодогенераторы (чаще всего работаю с Yii и просто добавил в gii нужные генераторы), процесс развертки CRUD приложения занимает примерно столько же времени — достаточно натравить эти самые генераторы на БД.
Но это уже в рамках обмена опытом (хотя в формате комментария наверное не очень понятно получилось) — не сочтите за критику. А в это приложение было бы неплохо еще добавить возможность открыть несколько пунктов меню одновременно (например в отдельных табах), их сохранение между перезагрузками страницы, и stateful для гридов.
А зачем запрашивать данные для формы редактирования у сервера? Они же есть в хранилище грида.
Там даже при нажатии на «Add in form» летит запрос на сервер и приходится ждать подгрузки формы.
Судя по примеру приложения по ссылке с гитхаба, тут та же беда, что и со многими другими приложениями, которые используют Ext 4+ — пишется куча вьюх/моделей/хранилищ/контроллеров, затем они по мере неоходимости подгружаются с помощью Ext.Loader (или, в данном случае, каким-то его Netzke-аналогом).
В итоге получается — жмем кнопку чтобы вызвать форму редактирования, уходит запрос на сервер, юзер ждет. Через какое-то время (в зависимости от качества интернетов и всякого такого) форма догружается и появляется на экране.
Юзер (и часто разраб, если он не еще не вник в Ext, а только начинает) делает вывод что Ext это медленно и неповоротливо.
В большинстве случаев 4-й экст есть смысл использовать только в связке с Sencha CMD. Ну или руками собирать все в кучу и скармливать в какой-нибудь closure compiler. Но это муторно.
Ну вот я о том и говорю, что экст не просто хелпер для быстого создания графического интерфейса типа гридов etc, это вполне себе полноценный mvc fw, я не согласен что можно сказать экст — это UI-ный фреймворк. В общем-то, никто не мешает не юзать экстовый UI — хоть джейквери цепляй да отображай как хочешь.
> Зачем статике апач
Этого я не понял…
Статику (css, js… ) лучше раздает nginx, а он .htaccess не понимает. Ну хотя это не большая проблема.
> По работе с сервером что-то тоже ничего не нашел готового в доках
Это frontend… он не диктует на чем написан backend… либо я не понял вопроса
Я имею ввиду — мне нужно отправить запрос на сервер. Ну например для той же авторизации. Или для CRUD. Аякс руками писать? В коробке никаких аяксов нету?
Справедливости ради, ExtJS это далеко не только UI fw. Там и работа с данными, и MVC, и шаблонизация, т.д.
С выходом Sencha Cmd каркас аппликухи вообще парой строк в консоли делается. А потом минифифицируется и всякое такое.
Имхо — не совсем уместное сравнение.
В доках смутило:
.htaccess — need for correct working framework
Зачем статике апач?
По работе с сервером что-то тоже ничего не нашел готового в доках — руками работать?
Там в доках авторизация вообще интересная:
if (username && password) {
//Do login, if any credentials were entered
$.cookie("isLogin", true, {path: "/"});
...
} else {
alert("Please enter login and password!");
}
Ну спишем на упрощение для примера.
Хотя на сайте написано — Architectural Web UI Single-Page Application (SPA) Framework.
Тогда тем более с экстом и т.п. сравнивать не нужно, это он UI — ный)
А что делать, если он не поддерживает File API, а тут используется именно он.
Если критично — можно все же остановиться на флеше, но экст это обычно админки, веб-морды к БД, что-то интранетное, там вы всегда можете обозначить рекомендуемые браузеры. Да и IE скоро подтянется — если не ошибаюсь 10й уже поддерживает File Reader API.
Похоже действительно особенной… Мы дочке тоже учебники сами покупаем. Причем там еще надо побегать — одна школа по одной программе учится — там один учебник, другая — по другой — уже и автор у учебника другой. Не просто так — пришел и купил учебник математики за 7й класс.
Это не шаблон, с которым сравнивается распознаваемое изображение.
Это после обучения выяснили, какое изображение дает максимальное значение на выходе. По первой ссылке в статье подробно описано.
Ну, сковородкой тоже убить можно, однако она не в состоянии осознать себя как личность и захватить кухню )
Ограничения свобод не от прогресса/науки, они от менталитета.
В чем, например, разница — будете вы JQuery-вскими $.ajax () на сервер с рельсами ходить, или экстовым прокси?
Ну вот поэтому я и оговорился, что в формате комментария ничерта не понятно )
Там генерится специфичная конфигурация — поля моделей, колонки гридов и всякое такое. Все общее — в базовых классах моделей/контроллеров. При этом в конкретном случае все можно переопределить.
У меня давно назрело желание по этому поводу накатать статью(и), т.к. в рунете не оч много вменяемой инфы по архитектуре экстовых приложений вообще, и Sencha CMD в частности. Да все никак время выбрать не могу. А в комментах, конечно, особо не объяснишь ничего.
У меня просто немного другой случай — нужно быстро поднимать морды для работы с данными (например бухгалтерская аналитика, закупки, сметы). Причем у каждого заказчика довольно специфическая логика и бизнес процессы, да и просто, как они это называют — «хотелки», под которые приложения после кодогенераторов нужно нужно подстраивать.
В этом случае отказ от MVC экста сильно чреват — завтра у них будет новая «хотелка» или изменения в бизнес-процессах, и будет армагеддон, если я описывал логику в гридах.
Поэтому поднялся фреймворк приложения — обработка меню, смена языка/тем/ интерфейса, базовые классы, кодогенератор. Приложение генериться, логика/вьюхи подтягиваются, sencha app build — на сервер.
Просто разные сферы применимости.
Колонки грида и поля формы да, могут.
Я люблю толстые модели и тонкие контроллеры, поэтому поступил следующим образом — в базовом классе модели, от которого наследуются все остальные модели, описал метод getEditForm(). Если для модели установлено свойство editForm (например: editForm: 'app.view.User.edit'), то возвращется ее инстанс с загруженным record, иначе — создается и возвращается дефолтная форма редактирования, в которой присутствуют все поля модели, для которых не установлен признак editable: false.
В итоге получается довольно удобно и гибко — по нажатию кнопки в контроллере достаточно дернуть record.processEdit(), который, в свою очередь, сделает нужные проверки, покажет форму и т.д.
Учитывая что я тоже испорльзую кодогенераторы (чаще всего работаю с Yii и просто добавил в gii нужные генераторы), процесс развертки CRUD приложения занимает примерно столько же времени — достаточно натравить эти самые генераторы на БД.
Но это уже в рамках обмена опытом (хотя в формате комментария наверное не очень понятно получилось) — не сочтите за критику. А в это приложение было бы неплохо еще добавить возможность открыть несколько пунктов меню одновременно (например в отдельных табах), их сохранение между перезагрузками страницы, и stateful для гридов.
Там даже при нажатии на «Add in form» летит запрос на сервер и приходится ждать подгрузки формы.
В итоге получается — жмем кнопку чтобы вызвать форму редактирования, уходит запрос на сервер, юзер ждет. Через какое-то время (в зависимости от качества интернетов и всякого такого) форма догружается и появляется на экране.
Юзер (и часто разраб, если он не еще не вник в Ext, а только начинает) делает вывод что Ext это медленно и неповоротливо.
В большинстве случаев 4-й экст есть смысл использовать только в связке с Sencha CMD. Ну или руками собирать все в кучу и скармливать в какой-нибудь closure compiler. Но это муторно.
Статику (css, js… ) лучше раздает nginx, а он .htaccess не понимает. Ну хотя это не большая проблема.
Я имею ввиду — мне нужно отправить запрос на сервер. Ну например для той же авторизации. Или для CRUD. Аякс руками писать? В коробке никаких аяксов нету?
С выходом Sencha Cmd каркас аппликухи вообще парой строк в консоли делается. А потом минифифицируется и всякое такое.
Имхо — не совсем уместное сравнение.
В доках смутило:
.htaccess — need for correct working framework
Зачем статике апач?
По работе с сервером что-то тоже ничего не нашел готового в доках — руками работать?
Там в доках авторизация вообще интересная:
Ну спишем на упрощение для примера.
Хотя на сайте написано — Architectural Web UI Single-Page Application (SPA) Framework.
Тогда тем более с экстом и т.п. сравнивать не нужно, это он UI — ный)
Если критично — можно все же остановиться на флеше, но экст это обычно админки, веб-морды к БД, что-то интранетное, там вы всегда можете обозначить рекомендуемые браузеры. Да и IE скоро подтянется — если не ошибаюсь 10й уже поддерживает File Reader API.
Это после обучения выяснили, какое изображение дает максимальное значение на выходе. По первой ссылке в статье подробно описано.
Ограничения свобод не от прогресса/науки, они от менталитета.