Comments 15
Я правильно понимаю, что все просто, и решается в конструкторе, пока дизайн от ExtJS?
Тут написано, но пока не попробуешь не очень понятно. Если не сложно, в 2-х словах расскажите.
Это не совсем относится к теме статьи. В платформу интегрировано несколько модулей, реализующих функционал схожий с CMS. На той странице описано как работать со страницами блоками и меню, которые отображаются на frontend, дизайн публичной части не обязательно должен использовать ExtJS.
дерево с поддержкой drug & drop

панель, отображающая структуру проекта, поддерживает Drug & Drop

Дерево и панель поддерживающие наркотики, это действительно круто! =)
P.S. Поправьте в тексте (drag)
А потом вы поймете что надо было не код генерить, а хранить результаты дизайна как данные, и их рендерить. Но уже будет поздно.
Результаты дизайна лежат как данные в файле проекта. Код генерится/рендерится при изменении данных и первом отображении.
В файле проекта. А должны быть в базе системы — такие же данные как и все остальные. Доступные через тот же слой доступа к данным.
Это добавило бы гибкости без особенных затрат — глядишь, заказчики сами бы себе формы добавляли…
Заказчики могут себе добавлять формы если им дать доступ. Стоит ли это делать, другой вопрос. Файл проекта чем не база системы? За сохранение данных отвечает абстрактный слой хранилища, при желании можно сохранять проект в СУБД или любом другом месте. Приведите пример проекта, в котором UI лежит в базе системы. Возможно я вас неверно понимаю, что вы подразумеваете под базой?
А в чем прелесть генерации js кода для построения интерфейса, если ext поддерживает постройку формы через json? Не облегчило бы это реализацию, путем простой сериализации обьектов в json?
Хранение объектов в формате JSON значительно усложнило бы реализацию. Кроме самой структуры расположения есть еще события, методы (+ исполняемый код), связи, наследование. Пришлось бы делать двойную работу генерировать этот JSON, потом распознавать для внесения изменений.
Ну при наследовании, можно же сделать компонент уже готовый, написать на js и подключить, и вызывать его через xtype, чем описывать тот же компонент через класы в php?
Да, конечно можно, так и делают. В нашем случае была задумка сделать визуальный редактор. Тут либо писать парсер ExtJS, либо генерировать код ExtJS, что значительно проще. Вы верно подметили, что логику создания интерфейса можно было бы полностью перенести на сторону клиента и это была бы совсем другая история со своими проблемами и решениями. Одна из задач, поставленная перед проектом — генерировать интерфейсы автоматически на стороне сервера на основе ORM.
Просто я решал такую же задачу, и автоматическая генерация форм, и по описанию в xml. Но реализовывалось генерацией json, правда тогда мы только знакомились с ExtJS, версия была помоему 3.5. Идея была немного в другом ключе, тоесть мы описываем формы одними обьектами (или автоматически или в xml), а в зависимости какая форма нам нужна ExtJS или обычная HTML выбирали специальный класс для рендеринга єтих обьектов. Вот сейчас собираюсь написать новую версию, учитывая все косяки которые были в предидущей реализации, и новые возможности. И возникла такая идея, есть круд контроллер, обычными 4 методами, и 5-й метод получение описания модели завязаной на этот контроллер, тоесть один метод всегда возвращает описание модели, а все другие гриды и формы используют эту модель, при чем загвоздка в том что отдавать js или json. Пока больше склоняюсь к json т.к. в реализации проще.
не совсем понял про локализацию. язык сменить можно только перед компиляцией?
В нашем случае за язык отвечает отдельный модуль, внутри дизайнера используется вызов конструкций JS, например appLang.someWord. Язык переключается в настройках системы. К странице подключается нужный файл локализации, тексты автоматически заменяются. Эти действия не требуют перекомпиляции.
Only those users with full accounts are able to leave comments. Log in, please.