ExtJS и серверный фреймверк - как лучше сделать?
 

Интересует вопрос о том, как лучше использовать ExtJS с серверными PHP-фреймверками.

То есть, вопрос по архитектуре приложения.

Когда начинаешь работать с ExtJS, получается, что вся логика сосредоточена на клиенте в JavaScript. А на сервере должны существовать только сервисы-ответчики, которые предоставляют данные (по AJAX) клиентским JS-моделям.

Поэтому вопрос 1 - имеет ли смысл использовать ZendFramework или там Yii или там CodeIgniter? Или это будет сплошной оверхед? Достаточно ли просто пользоваться на сервере возможностями PHP плюс какой-нибудь ORM?

Вопрос 2 - где и как хранить код объектов ExtJS? Хранить как статику в в видет простых файлов в директории? Хранить в директории видов PHP-фреймверка и генерировать JS-код PHP-фреймверком? Какие-то смешанные техники?

Вопрос 3 - имеет ли смысл использовать совместно с ExtJS библиотеку JQuery?

В общем, расскажите, как у вас устроены приложения с ExtJS.

1. Я не пхпшник, поэтому хз. Вообще очевидно зависит от того какая логика ожидается на сервере, и нужны ли навороты предоставляемые фреймворками. Системы "навороченный клиент" + "навороченный сервер" тоже возможны и встречаются, все зависит от задач.
Там где я работаю, сервер написан на .net и логики там много.
На клиенте тоже много)

2. Генерировать приложения на extjs серверным php? Мсье знает толк) По каким причинам Вы собираетесь это делать?)
View мы правда тоже генерим с помощью sencha architect, но самому писать такую штуку убьешься.
архитектура взаимодействия - rest
Код храним просто как статические файлы, mvc позволяет в них не путаться, на продакшне храним минифицированный файл для юзера и все остальное для отладки.

3. Я такое тоже видел, использовать их вместе вполне возможно даже в больших приложениях, они друг друга не переписывают. Вот только зачем? Jquery - это как шило. Им можно успешно делать что-то одно, лаконично и хорошо. Extjs - это как швейцарский армейский нож - в нем есть все необходимое, и еще вагон всего что никогда не пригодится. Шило тоже есть, правда не столь удобное.

Ну, например, когда нужно сделать универсальный класс экранной таблицы. Чтобы не в JS коде статически прописывать имена полей, URL-ы для CRUD-обработчиков и прочие свойства. А чтоб весь этот JS-код генерировался на сервере.

Или так не делается, ибо очень сложно?

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

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

Понял, спасибо.

Sencha Cmd создаёт свою структуру директорий
 

Компания Sencha бесплатно раздаёт разработчикам приложений на ExtJs свой продукт для автоматизации Sencha Cmd

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

У меня структура директорий выглядит приблизительно так:

В директории ext-4.2.1 я запустил sencha generate workspace, чтобы заполнить директорию workspace.
Затем из директории ext запустил sencha generate app, чтобы заполнить директорию superfotoalbum.
Код приложения помещаю в директорию app, а в браузере открываю index.html, который расположен уровнем выше.
Когда всё готово, запускаю из директории app команду sencha app build, которая собирает приложение и кладёт его в папку production/Superfotoalbum.
Для окончательной проверки открываю index.html из этой папки, а затем переношу всё её содержимое в директорию client, которую и отправляю на боевой сервер.
На сервере лёгкий MVC-фреймворк на PHP(bulletphp) или NodeJs (express). Общение браузера с сервером чистый Ajax, Rest или RPC.

Может иметь смысл если у вас много гридов.. но вряд ли правильно на каждый запрос дергать базу данных. Я делал вариацию на эту тему .."полуавтоматика": генерим статические js классы скриптом один раз (ну и можно перегенерировать вручную если структура таблиц поменялась)

У нас небольшие веб приложения. База на Oracle.

Я вообще сделал свой мини Web сервер на Java, который умеет отдавать статичные файлы с настроенной папки с кэшированием (ext, свои приложения) и по определенному урлу передавать json данные в БД Oracle в процедуры (через clob переменные), которые уже делают в БД то что требуется.
Никаких прослоек в виде php и прочих серверных скриптов нет :)
Веб сервер поддерживает сессионность.

Но повторяюсь, у нас небольшие веб приложения - не сложные.

Вот тут есть описание одного такого нашего приложения:
http://absinversion.blogspot.ru/2014/06/blog-post.html

novikov,
Подскажите, пожалуйста, мне нужна подобная структура

--public
----index.html
----build
----src
------app.js
------app

Как заставить bootstrap.js искать файлы не в public, а в src?
Как билдить в build?

ExtJs берет на себя кучу работы. в этом и + и -.
поэтому архитектура приложения может быть вырождена до примитивизма на более низких уровнях (база, бизнес).

1) достаточно тупых ответов базы, обернутых в json.
2) статика js очень сильно упрощает сопровождение. любой автогенеримый код - головная боль поддержки.
3) нет. ExtJs имеет очень мощные средства подобные jQuery.

быстро-бегом архитектуру текущего проекта упомянул тут
http://bastrakof.livejournal.com/363117.html

1) Ext JS работает с сервером при помощи RESTfull. Этот протокол является основным для Ext, но не обязательным. Этот протокол хорошо поддерживает Zend Framework 2. Там все уже есть. Я лично сам так и соединяю клиент и сервер. Работает на ура.

2) Клиентскую часть на Ext можно хранить в рамках приложения на Zend Framework 2, а можно хранить вообще в другом месте. Как удобнее разработчику. Я генерирую при помощи Zend Framework 2 только первый index.html чтобы туда заложить настройки Ext-приложения.

3) Не имеет. Но мне больше нравится JQuery, чем Ext, в плане работы с селекторами. Поэтому я их иногда смешиваю.

Поправка: Ext JS работает с сервером при помощи Proxy, которых есть много разных на любой вкус. Помимо REST в коробке есть ещё JsonP и Ext.Direct. Я всегда пропагандирую последний, т.к. на мой взгляд RPC интерфейсы имеют массу преимуществ перед REST во многих приложениях, и изрядно недооценены.

Можно к этому добавить, что если штатные варианты транспорта чем-то не устраивают, то вам никто не мешает написать свой вариант прокси. Как примеры можно привести SOAP и AMF, которые хоть и не идут в штатной коробке Ext JS, но доступны как пакеты в Sencha Complete.

Да, действительно. Правда работая с Ext у меня сложилось ощущение что именно RESTfull для них самый главный.

RESTful интерфейсы очень просто сляпать по-быстрому для примеров, именно поэтому они и доминируют и в документации, и собственно в примерах кода.

Для больших живых приложений ситуация не совсем совпадает. Да, правильно спроектированный RESTful интерфейс может решить все или почти все задачи, но кто и где видел правильно спроектированный RESTful интерфейс? Я вот лично не видел, везде хак на косяке и костылём подпирает.

RPC в этом смысле гораздо лучше хотя бы в силу своей унифицированности. Когда нет вопроса "как лучше передать параметры в функцию на сервере", то и время на поиски решения не тратится. Просто бери и используй.

Хотя я конечно понимаю, что "просто бери и используй" не очень интересно, RESTful велосипеды изобретать гораздо увлекательней. ;)

Спасибо за ответ. В следующем проекте обязательно попробую RPC вместо REST. А то я RPC так, теоретически знаю что он есть, как соап и прочее.

SOAP городить ради своего проекта смысла нет, это очень специфическая штука. В Ext JS есть коннектор для SAP, который по SOAP разговаривает, но протокол довольно сложный и если у вас на серверной стороне не SAP, то и не нужный вовсе.

Смотрите в сторону Ext.Direct, это более простой вариант RPC.

Ext.direct интересен пакетной отправкой запросов на сервер. Использовал с четвёртой версией ExtJs. Не обязательно запрашивать сложные вложенные структуры, чтобы сократить количество запросов и ускорить работу приложения. Возможен простой маппинг: таблица в базе - модель в ExtJs. Там есть хитрость - запросы отправляемые из форм имеют особый статус. Нужно правильно догадаться, как загружать файлы. Вообще, удобно запускать серверные функции прямо из клиентского кода.

Сейчас использую REST-подобное API, потому что мой PHP код утрачен и не было времени писать этот слой под пятую версию ExtJs. Но главная причина в том, что с сервером работет не только ExtJs, а ещё, например, Jira. Не писать же на Джаве механизм подобный директу. Да и тема о лицензиях на форуме и потенциальное сокращение сообщества заставляет думать об ослаблении привязки к особенностям Экста.

В ресте у меня CRUD для каждой таблицы базы данных. Причём read существует в трёх вариантах: 1) одна строка для форм; 2) несколько строк с фильтрацией, группировкой и разбиением на страницы для гридов; 3) одна строка таблицы, но в виде вложенной структуры, которая содержит данные из связанных таблиц, для кастомных компонентов.

а что там с лицензиями не так? хотят бесплатное отменить?

нет, не хотят. Нельзя теперь купить лицензию на одного разработчика, а только на пятерых, и цена у неё конская. И ещё не все релизы ExtJs имеют бесплатную версию.

А для чего конкретно в России покупают Ext JS? Разве нельзя обойтись бесплатной версией?

Лицензия GPL заражает всё коммерческое решение оперсорсностью.


GNU GPL не позволяет включать программу в проприетарное ПО

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