GWT с несколькими хост-страницами в устаревшем приложении

Question

Я рассматриваю возможность использования GWT в качестве внешнего интерфейса для существующего веб-приложения.

Я не могу оправдать полное переписывание на 100% GWT за один раз. Вполне вероятно, что я постепенно перенесу части системы в GWT. Однако для согласованности я хотел бы использовать GWT TabPanel, MenuBar и т. Д. В качестве глобальных элементов интерфейса с первого дня.

В качестве эксперимента, чтобы увидеть, как «устаревшие» части системы могут быть включены, я сделал следующее.

Шаблон главной страницы приложения теперь загружает небольшой GWT-модуль «оболочки» на каждую страницу. Этот модуль GWT ищет выбор DIV на динамически генерируемой странице хоста. Если DIV найден, подходящий виджет вставляется на место, то есть menuBar, tabPanel.

Большая часть конфигурации для включенных виджетов также может быть размещена на странице хоста в виде структур JSON. Например, я реализовал адаптер, который динамически настраивает TabPanel таким образом. Я также добавил несколько очень простых виджетов, которые загружают удаленный HTML и т. Д.

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

Может ли кто-нибудь высветить какие-либо проблемы, с которыми может столкнуться вышеупомянутый подход, особенно с увеличением размера модуля GWT? Я хотел бы сохранить устаревший модуль-обертку преднамеренно худым. Другие функциональные возможности будут реализованы в отдельных модулях.

Как другие люди постепенно интегрировали GWT в свой интерфейс?

Answer 1

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

Это не будет иметь большого значения, но я хотел бы предложить не помещать код JavaScript GWT в ваш основной шаблон, а размещать его только на тех страницах, где это необходимо. Это правда, что если вы не используете HTTP, он кешируется в основном навсегда, но кажется неправильным заставлять людей загружать модуль, если он на самом деле не нужен на этой странице. Это, конечно, зависит от того, как люди используют ваш сайт, и если они все равно его скачают, это ничего не изменит.

Answer 2

Вы делаете это правильно. Избегайте избегать искушения попытаться «минимизировать» занимаемую площадь GWT, разбив ее на несколько отдельных приложений.

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

y-slow & firebug может быть действительно полезным, когда дело доходит до убеждения себя в этом.

Один трюк с производительностью, который вы можете попробовать, доступен в главе с примерами здесь: http://www.infoq.com/articles/progwt Он показывает мини-архитектуру вокруг загрузки виджетов GWT в любое количество слотов и предварительного заполнения данных в переменных JavaScript. Это позволяет загружать ваши виджеты GWT и не требует второго HTTP GET для получения данных, которые они используют. На практике я обнаружил, что это хороший прирост производительности.