Превращение в JavaScript как неотъемлемую часть интерфейса против DHTML

Question

Более общий вопрос здесь.

В настоящее время многие проекты, над которыми я работаю, используют серверные представления для визуализации пользовательского интерфейса и добавляют его JavaScript-то здесь и там. Это хорошо для небольших проектов, но в последнее время кажется, что файлы .js становятся довольно большими по размеру, и стеки на вызовы jQuery стеков .live и .bind, похоже, уже не сокращают его.

Каковы хорошие способы смешать JavaScript с представлением и, возможно, контроллером веб-приложения? Для веб-сайтов на основе Java я нашел DWR весьма полезным, но во многих случаях инициируемые пользователем события требуют логики контроллера, которая начинает становиться подавляющей и сбивающей с толку, когда она является частью многих одиноких функций, включенных в страницы.

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

Каков хороший подход "среднего уровня", используемый веб-приложениями, которые не полностью свободны от AJAX и не полностью ориентированы на JavaScript?

EDIT: Возможно, я приведу повседневный пример проблемы. Скажем, я хотел бы предоставить пользователю модальный диалог, подтверждающий или опровергающий что-то:

"Your picture is uploaded but looks terrible. You need a new 'do." (OK | What?)

Теперь в одном сценарии это диалоговое окно может появиться в результате загрузки изображения с обновлением страницы, и в этом случае представление на стороне сервера будет отображать его. В другом сценарии оно может появиться после загрузки изображения через AJAX, и в этом случае оно, вероятно, будет вызвано JavaScript на странице. В обоих случаях нам нужен доступ к коду создания диалога, и я пока не могу придумать, как, скажем, класс Dialog, который бы работал одинаково в обоих случаях.

Answer 1

Я, конечно, не эксперт в этой области, но в прошлом я работал с проектами, использующими сервисы RESTful, которые, казалось, хорошо вписывались в мир разработки веб-сайтов AJAXY.Я не могу сказать, что это было бы идеально для веб-приложений, но отлично работало для содержательных презентационных сайтов.Кажется, что это будет соответствовать вашим потребностям в мульти-презентационных форматах с помощью пользовательских шаблонов.Таким образом, служба может вызывать службу pictureUpload с использованием шаблона страницы HTML или может вызывать службу и запрашивать шаблон компонента AJAX.

Answer 2

Я недавно работал с JavascriptMVC (2.0) для внутреннего приложения компании. У этого есть свои недостатки, но общая архитектура хороша и позволяет вам создавать классы JS контроллера. Каждый контроллер «владеет» подмножеством дерева DOM (или, если хотите, визуальной частью страницы) и реагирует на события в этой зоне и использует шаблоны EJS (часть «представление») для изменения районы под ним. Он хорошо абстрагирует то, что в противном случае было бы большим количеством вызовов $(...).bind() и $(...).live() в модели ООП.

В моем случае наш интерфейс почти на 100% основан на JS из-за ограничений вокруг проекта, но нет никаких причин, по которым вы не можете использовать mix-n-match.

Теперь в одном сценарии это диалоговое окно может появиться в результате загрузки изображения с обновлением страницы, и в этом случае представление на стороне сервера будет отображать его. В другом сценарии оно может появиться после загрузки изображения через AJAX, и в этом случае оно может быть вызвано JavaScript на странице

Вот как я могу это сделать так, чтобы это работало даже при отключенном JavaScript:

1. На стороне сервера выводится форма загрузки в формате HTML. Форма в формате обычного HTML будет отправлена ​​на другую страницу PHP.
2. Фрагмент Javascript запускается по завершении загрузки страницы в поисках этой формы.
3. javascript создает экземпляр HairdoUploadController, передавая <form>...</form> конструктору.
4. Контроллер «принимает» форму, используя селекторы JQuery, чтобы изменить стиль и перехватить форму, отправляющую события.
5. Контроллер добавляет новый div и связывает его с (изначально скрытым) диалогом Jquery-UI.
6. Когда форма отправляется, контроллер вместо этого выполняет вызов AJAX по несколько другому URL-адресу, чем обычная форма.
7. Результаты вызова AJAX помещаются в div диалогового окна, и отображается диалоговое окно.

Answer 3

Похоже, Google Web Toolkit может быть то, что вы ищете.

Позволяет писать на стороне клиента. приложения на Java и их развертывание как JavaScript.

Предположительно, тогда вы могли бы написать код один раз на Java и использовать его в обоих местах, хотя сам я никогда не использовал GWT.

В своей собственной среде, которую я разрабатываю, я в основном заставляю разработчиков писать код дважды. Один раз на родном языке и один раз на JavaScript. Я заставляю их заполнять функцию, которая возвращает JS, и затем она может вызываться автоматически там, где это необходимо. Но весь код содержится в одном классе, так что, по крайней мере, у вас нет разбросанной логики повсеместно, и вы можете быстро сравнить, если они функционально эквивалентны. Для таких вещей, как регулярные выражения, его обычно можно написать один раз, а затем передать в JS (я использую его для проверки один раз на стороне клиента, а затем снова на стороне сервера).

Answer 4

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

Существует два сценария:

1. Запрос без Ajax
2. Запрос Ajax

Единственное различие между ними состоит в том, что в первом вы визуализируете больше контента, чем просто модальное диалоговое окно. Нет причины, по которой у вас не может быть класса Dialog на сервере, который выдает HTML-представление диалога и используется для обоих типов запросов. Затем в вызове AJAX вы просто добавите ответ сервера в DOM.

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

Answer 5

Я недавно обнаружил, что использую свой код на стороне сервера (в моем случае ASP.Net MVC) в качестве средства обеспечения повторного использования компонентов компоновки (основных файлов) и небольших инкапсулированных битов пользовательского интерфейса (частичные представления), и делает изрядное количество работы в javascript. В этом конкретном случае я все еще довольно рано в своей работе с пользовательским интерфейсом, но с jQuery и jQuery UI у меня много функциональных возможностей в очень маленькой области.

Я думаю, что одной из проблем, связанных со смешанным решением, является выяснение, где разместить различные кусочки логики. После этого остальное, вероятно, пойдет на выяснение того, как повторно использовать как можно больше вашего javascript и css кода. Я до сих пор не выяснил, как управлять различными артефактами javascript, с которыми я сталкиваюсь (хотя Google CDN избавляет от этого, предоставляя jQuery, jQuery UI и ресурсы CSS jQuery UI).