Работая над своим приложением, я столкнулся с необходимостью обновления стандартного компонента Table данными из периодически обноляющегося javascript массива, находящегося на клиенте в общей области видимости.
В двух словах ситуация следующая: имеется кастомный див с внутренними фичами, которые создаются javascript фреймворком dojo в связке с парой дополнительных библиотек. В процессе создания этих фич, информация о них заполняет Vaadin-активные контролы приложения (table, tree и т.п.). Вызов экшенов этих контролов запускает внешние javascript методы, в том числе и REST запросы ко внешним источникам данных. Результаты подобных запросов коллекционируются в javascript массив, который хочется использовать для обновления , например, subwindow с Vaadin Table.
Недельные изыскания на эту тему привели меня к весьма скромному описанию возможности расширения стандартных GWT виджетов с последующей интеграцией с Vaadin, которая, тем не менее, не позволяет, насколько я понял, обновлять содержимое кастомизируемого компонента так, как мне необходимо.
В связи с этим есть вопрос, возможно ли получить требуемую функциональность созданием виджета НЕ на основе GWT Table, а на основе Vaadin Table, расширив клиентский класс на необходимые методы с использованием JSNI и оставив “базовую” функциональность таблицы в исходном виде?
Пробовать расширять Table (и уж тем более его клиентскую реализацию VScrollTable) - я бы не советовал (хотя исследования на тему переписания всего компонента уже ведутся). Тем более все таки за аккумулирование данных отвечает не сама таблица, а ее контейнер. Поэтому на вскидку я бы вам предложил создать что то вроде вспомогательного виджета (с клиентской реализацией, скорее всего невидимый), который будет получать результаты ваших запросов и в том или ином виде пересылать их на сервер. На сервере вы создаете из результатов Item’ы и добавляете их в контейнер, который автоматом сообщит таблице о том, что ей необходимо себя перерисовать. Тут, конечно, данные ваших запросов лишний раз слетают на сервер и вернутся обратно, но для работы Table - они точно как то должны оказаться в контейнере, так что это неизбежно. В качестве отправной точки я бы выбрал адд-он
Widget RPC (автор его как раз и написал, чтобы удобнее получать данные из внешних JS API).
надеюсь это как то поможет. Если будут какие то поправки/предложения - пишите =)
Указанный Widget RPC адд-он принят на вооружение, но, все же, остается неясной возможность связывания клиентских событий, захендленых в кастомизируемом (невидимом) компоненте, с внешними, по отношению к нему же, DOM событиями.
То есть, например, чтобы произвольный вызов в пределах скрипта src=""+ themeUri + "/js/main.js" вида dojo.connect(queryTask, “onComplete”, showResults) передавал полученный JSON в произвольный метод showResults(String results), но кастмизируемого класса, а не в отдельный javascript метод.
Насколько я понял, подобного рода связывания возможны только в пределах компилируемого GWT контекста или я что-то упустил?
Ну вроде да, мне кажется, что так или иначе можно свести проблему к написанию JSNI-оберток над существующими JS библиотеками (хороший тому пример - InvientCharts, являющийся оберткой HighCharts и реагирующий на всяческие события). Помимо этого существует еще более изощренный способ связывания GWT приложений и JS библиотек (основанный на генераторах компилятора GWT) -
gwt-interop
