Поиск мнений о некоторых архитектурных решениях для веб-интерфейса Ext JS на основе

Question

Я начал работу над небольшим программным проектом, в основном, через веб-программу выставления счетов.Я хочу, чтобы его можно было использовать со смартфонов.Я выбрал бэкэнд - Perl - Dancer - Moose - Kiokudb, которым я сейчас очень доволен (да, я знаю, что некоторые уже есть).

Сейчас я пытаюсь сделать выбор над уровнем представления проекта.Первоначально я думал, что традиционный шаблон HTML, страница для каждой функции типа расположения.Прошлой ночью я начал смотреть на Ext Js / Sencha.Это выглядит довольно аккуратно, и я вижу, как это может сделать довольно хороший интерфейс для чего-то вроде приложения для выставления счетов.Я хотел бы подумать о том, что является идеальным способом справиться с генерацией форм.На мой взгляд, у меня есть несколько вариантов с Ext Js (или Dojo, или любой из этих фреймворков). 1. Я мог бы закодировать каждую форму непосредственно в файл Javascript, который, по-видимому, является маршрутом, наиболее подходящим для демонстрации.Но мне кажется неудобным кодировать HTML-форму в Javascript, когда я могу просто написать ее в HTML?Я что-то упустил?

1. Я мог бы динамически генерировать формы из данных. Это означает, что мне нужно было бы хранить метаданные, связанные с данными, которые я мог бы делать в Moose, используя черты.Но тогда как вы справляетесь с такими вещами, как порядок показа, чтобы не запутаться?Что вы думаете о сохранении метаданных отображения с объектом данных?

2. Я все еще мог бы генерировать формы с использованием HTML-шаблонов и использовать Ext Js для их улучшения, но это не так.поощряется Ext Js, хотя это возможно.

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

Любые мненияна что ты думаешь лучше?

Answer 1

Я написал несколько крупных веб-приложений со слоем представления на основе Ext Js (все они используют ASP.Net на стороне сервера). Мое первое приложение было написано как традиционный HTML и дополнено Ext Js на клиенте. Теория здесь заключалась в том, что некоторые конечные пользователи могут воспользоваться возможностью выполнить без JavaScript. На самом деле этого никогда не было. Конечно, это был не веб-сайт в стиле Amazon.com.

Следующая пара приложений в значительной степени отказалась от HTML. У нас были некоторые опасения по поводу использования «нестандартного» уровня представления. Но так просто спроектировать макет Ext. Мы обнаружили, что непрограммисты могут посмотреть на макет Ext (это просто объект JavaScript) и понять почти все. Также легко загружать новые файлы JavaScript динамически; так что мы могли бы вырастить приложения естественным образом.

В настоящее время у нас есть несколько традиционных страниц ASP.Net (для входа в систему, фатальных ошибок и т. Д.) И уровень контроллера в C #. Только одна страница ASP.Net необходима для канала от JS до C #. Остальная часть уровня представления сделана в Ext Js. Мы фактически использовали этот дизайн для создания автономного приложения одного из наших приложений. Для этого нам нужно было только заменить несколько страниц ASP.Net (мы могли повторно использовать 100% кода Ext Js и 100% кода C #).

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

Answer 2

Не знаю, если готово добавить еще одну опцию, но dojo позволяет создавать формы в HTML, а затем превращать их в dijit (виджеты dojo) в браузере.

Answer 3

Я не использовал Ext экстенсивно, но я создал фреймворк для динамического приложения с POE :: XUL .Все формы генерируются из серии конфигурационных файлов YAML, которые также содержат метаданные о том, как данный элемент взаимодействует с серверной частью.И хотя я не сделал полную мощь XUL доступной для дизайнеров форм, это можно рассматривать как хорошую вещь.

В то время я думал, что использование Firefox или xulrunner для приложения в интрасети будет приемлемым.Оказывается, PHB очень нравится их MSIE.Тем не менее, Ext не был хорошим вариантом, когда я начал писать фреймворк.

В какой-то момент я надеюсь реорганизовать фреймворк, чтобы он работал со всеми браузерами, скорее всего с использованием Ext Js в браузере.Поскольку моя цель - приложения для интрасети, допустимо сказать, что «у вас должен быть включен JS».

И так как мои формы определены в YAML, я смогу переместить все приложения, написанные для XUL-только фреймворк для фреймворка Ext, и они должны просто работать.

Однако написание фреймворка, управляемого метаданными, является более сложной проблемой.Вы не указали свой уровень квалификации.Если вы только новичок, я бы предложил в браузере pure-Ext говорить с комендом к бэкэнду.