Конечно. Переход от Struts к AJAX-фреймворку очень полезен. (Хотя мы использовали JSON, а не XML. Гораздо проще разобрать.) Однако вы должны знать, что это фактически полная перезапись вашего приложения.
Вместо классической схемы Database / JSP / Actions для MVC вы обнаружите, что переходите к схеме Servlet / Javascript, в которой модель представлена HTTP-запросами GET, действия представлены запросами POST / PUT / DELETE и представление отображается на лету веб-браузером. Это приводит к интересным проблемам в каждой области:
На стороне сервера - На стороне сервера вам нужно будет разработать стандарт для предоставления данных клиенту. Самый простой и легкий способ - это применить методологию REST , которая наилучшим образом соответствует иерархии ваших данных. Это довольно просто реализовать с помощью сервлетов, но Sun также разработала схему Java 1.6 с использованием атрибутов, которые выглядят довольно круто.
Другим аспектом на стороне сервера является выбор протокола передачи. Я знаю, что вы уже упоминали XML, но вы можете пересмотреть. Анализаторы XML сильно различаются между браузерами. Один браузер может сделать документ корнем первого потомка, другой - добавить специальный объект контента, и все они анализируют пробелы по-разному. Еще хуже то, что функция normalize (), похоже, неправильно реализована основными браузерами. Это означает, что синтаксический анализ XML может быть полон хаков.
JSON анализировать намного проще и более последовательным в своих результатах. Javascript и Actionscript (Flash) могут переводить JSON непосредственно в объекты. Это делает доступ к данным простым вопросом x.y или x [y]. Существует также множество API для обработки JSON на всех мыслимых языках. Поскольку его так легко разобрать, он почти поддерживается ЛУЧШЕ, чем XML!
Клиентская сторона - Первая проблема, с которой вы столкнетесь, заключается в том, что никто не понимает, как писать Javascript. ОСОБЕННО тем, кто думает, что они делают. Если у вас есть какие-либо книги по Javascript, выбросьте их в окно СЕЙЧАС. Практически нет хороших книг по языку, поскольку все они следуют одной и той же схеме «взлома», не углубляясь в то, что делают.
Начиная с самого низкого уровня, ваша команда будет нуждаться в корректирующем обучении по разработке Javascript. Начните с Javascript Client Guide . Это де-факто источник информации о языке. Следующая остановка - видео Дугласа Крокфорда на Javascript. Я не согласен со всем, что он говорит, но он один из немногих экспертов по языку.
Как только вы это поняли, подумайте, какие фреймворки, если таковые имеются, вы хотите использовать. Вообще мне не нравятся такие вещи, как Prototype и Mootools. Они стремятся взять простую проблему и усугубить ее. Тем не менее, вы можете свободно оценить эти инструменты и решить, будут ли они работать на вас.
Если вы абсолютно уверены, что не можете жить без рамок, потому что ваша команда слишком неопытна, тогда GWT может соответствовать всем требованиям. GWT позволяет быстро писать веб-приложения DHTML в коде Java, а затем компилировать их в Javascript. ПРОБЛЕМА заключается в том, что вы отказываетесь от огромного количества гибкости, делая это. Язык Javascript намного мощнее, чем GWT. Тем не менее, GWT позволяет разработчикам Java быстрее набирать скорость. Так что выбирайте свои битвы.
Это ключевые области, о которых я могу думать. Я могу сказать, что вы вздохнете с облегчением, как только вы получите распорки из своего заявления. Это может быть немного зверя. Особенно, если у вас есть неопытные разработчики, работающие над вашей моделью Struts. : -)
Есть вопросы?
Редактировать 1: Я забыл добавить, что ваша команда должна изучать W3C спецификации неукоснительно. Эти API доступны в современных браузерах. Если вы поймали кого-либо, использующего API DOM 0 (например, document.forms ['myform']. Blah.value вместо document.getElementById ("blah"). Value), заставьте их транскрибировать всю спецификацию DOM 1, пока они не поймут ее. к низу.
Редактировать 2: Еще один ключевой вопрос, который необходимо рассмотреть, - это документировать ваше модное новое приложение AJAX. Интерфейсы в стиле REST хорошо поддаются документированию в вики. То, что я сделал, имело страницу верхнего уровня, на которой были перечислены все услуги и описание. Нажав на путь службы, вы попадете в документ с подробной информацией по каждому из подпутей. Теоретически, эта схема может документировать настолько глубоко, насколько вам нужно, чтобы дерево ушло.
Если вы используете JSON, вам необходимо разработать схему для документирования объектов. Я только перечислил возможные свойства в вики как документацию. Это хорошо работает для простых деревьев объектов, но может усложниться с более крупными и сложными объектами. В этом случае вы можете добавить что-то вроде IDL или WebIDL. (Не может быть намного хуже, чем XML DTD и схемы.; -))
Код DHTML немного более классичен в своей документации. Вы можете использовать такой инструмент, как JSDoc для создания документации в стиле JavaDoc. Есть только одна оговорка. Код Javascript не подходит для документирования в коде. Если по какой-либо другой причине, то факт, что он вздувает загрузку. Тем не менее, вы можете регулярно писать код, который работает как связный объект, но не кодируется за кулисами как такой объект. Таким образом, лучшим решением является создание файлов скелета JSDoc, которые представляют и документируют объекты Javascript.
Если вы используете GWT, документация должна быть легкой.