Комментарии 10
А если все тоже самое писать на обычных HTML+JS+jQuery? На чем писать быстрее, что оптимальнее, где кода меньше, легче поддерживать, развивать и пр.?
Ну я уверен, что чтобы реализовать проект, подобный приведенному демо на HTML+jQuery то кода в любом случае было бы меньше. А вот по мере развития и разрастания проектя я, как применяющий GWT, уверен что поддерживать будет сложнее.
Но это субъективное мнение, все конечно же зависит от профессионализма разработчиков, не важно на каких технологиях они работают, будь то либо GWT либо JavaScript
Но это субъективное мнение, все конечно же зависит от профессионализма разработчиков, не важно на каких технологиях они работают, будь то либо GWT либо JavaScript
Ну вот у меня точно такое же предчуствие, поэтому хочу найти людей которые поделились бы опытом использования GWT в большом проекте, хотя бы год.
спрашивайте ;) с GWT работаю больше года и проект не маленький
Спрашиваю ;) Какие основные сложности возникают при росте проекта? И есть ли они вообще? Что обычно спасает? Ну и помогают ли в данном случае тесты и code coverage?
Скажу для начала, что я и мои коллеги в проекте используем фреймворк mvp4g (http://code.google.com/p/mvp4g). Так уж исторически сложилось, когда начинали проект то GWT был в версии 2.0.х.
Так вот этот фреймворк позволяет организовывать приложение в подмодули (или подсистемы). Мы организовали архитектуру таким образом, что имеем главный модуль. Он отвечает за общий layout UI, обрабатывает сообщения глобального уровня (например, загрузить дочерний модуль, показать окно логина, отобразить главный виджет дочернего модуля в определенном месте UI, вывести уведомление и т.д.). Вся остальная полезная нагрузка реализуется в относительно автономных дочерних модулях. В каждом дочернем модуле имеется своя отдельная шина событий. События из нее могут поступать презентерам дочернего модуля, также есть возвожность отослать событие «наверх», главной шине. С ростом проекта мы просто добавляем новый дочерний модуль и там реализуем новый функционал. К примеру, модули у нас это contacts, messages ну и т.д. Поэтому трудностей с расширением никаких.
Сложности если и возникают то они скорее локальные и решаются проведением рефакторингов и «утряски» ивентов, которые должны формардится через главную шину другим дочерним модулям.
Если честно, то я пока (не смотрел другие проекты) для себя не представляю, как такую поддерживаемую и легко расширяемую архитектуру построить на JavaScript. Просто я не просвещен в этом вопросе.
Тесты конечно помогают, куда же без них. Тестируется логика, которая реализуется в презентерах. Но бооольшая часть тестов у нас это всетаки тесты серверного АПИ и Selenium-тесты
Так вот этот фреймворк позволяет организовывать приложение в подмодули (или подсистемы). Мы организовали архитектуру таким образом, что имеем главный модуль. Он отвечает за общий layout UI, обрабатывает сообщения глобального уровня (например, загрузить дочерний модуль, показать окно логина, отобразить главный виджет дочернего модуля в определенном месте UI, вывести уведомление и т.д.). Вся остальная полезная нагрузка реализуется в относительно автономных дочерних модулях. В каждом дочернем модуле имеется своя отдельная шина событий. События из нее могут поступать презентерам дочернего модуля, также есть возвожность отослать событие «наверх», главной шине. С ростом проекта мы просто добавляем новый дочерний модуль и там реализуем новый функционал. К примеру, модули у нас это contacts, messages ну и т.д. Поэтому трудностей с расширением никаких.
Сложности если и возникают то они скорее локальные и решаются проведением рефакторингов и «утряски» ивентов, которые должны формардится через главную шину другим дочерним модулям.
Если честно, то я пока (не смотрел другие проекты) для себя не представляю, как такую поддерживаемую и легко расширяемую архитектуру построить на JavaScript. Просто я не просвещен в этом вопросе.
Тесты конечно помогают, куда же без них. Тестируется логика, которая реализуется в презентерах. Но бооольшая часть тестов у нас это всетаки тесты серверного АПИ и Selenium-тесты
Весь код по инициализации и запуску механизма MVP-фреймворка собран в onModuleReary()-методе EntryPoint’а
По-моему, тут метод называется onModuleLoad()?
Спасибо за это руководство, лично для меня это очень полезный материал.
Мне, как новочку GWT, не понятно — что же лучше использовать — встроенный MVP фреймворк или mvp4g? У вас есть опыт использования и того и другого, поделитесь пожалуйста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в MVP GWT 2.1