какую технологию и архитектуру выбрать для табло

Question

Его всем,

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

Технология

Первый выбор технологии, который приходит на ум, - это GWT, который помогает поддерживать низкий трафик и позволяет целенаправленно обновлять области отображения (поскольку рендеринг происходит на клиентебоковая сторона).Исходя из моего опыта, у этого выбора есть некоторые минусы: портирование HTML и CSS из статических макетов в GWT требует гораздо больше времени, поскольку вы видите только сгенерированный HTML во время выполнения (UiBinder делает это несколько более удобным, но проблема в целомостается), DevMode мучительно медленен под Linux, и компиляция перестановок для одного развертывания может занять несколько минут.Что способствует гораздо более медленному времени разработки, чем, скажем, JSP или JSF.

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

Архитектура

Какой подходящий шаблон следует принять для этого случая.Я пытался иметь индексный объект, который содержал бы ссылки на другие объекты цен и предметов.Чтобы при изменении расположения ценников на экране появлялись новые, обновлялись старые, создавался и отправлялся клиенту новый индексный объект.Клиент знает, что дисплей должен быть обновлен, и отображает его заново.Положительным моментом является то, что он дает вам многократно используемых компонентов (цена и объект предмета), но с отрицательной стороны это то, что повторная визуализация всего экрана, если добавляется новый элемент, становится интенсивнее ЦП по мере появления новых обновлений.Также нет однозначного соответствия между индексным объектом и макетом страницы: поэтому, если ваш дизайнер выбрал макет на основе таблицы, и между элементом 1 и элементом 2 есть одна пустая строка, вы не сможете отобразить позицию индексаОбъект item находится на своей позиции в таблице владения без какой-либо дополнительной обработки.

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

Большое спасибо за ваши предложения!

Обновление: формулировка и стиль

Answer 1

DevMode мучительно медленно работает под Linux

В последнее время было несколько человек с проблемами производительности DevMode, и я действительно не уверен, почему это так. По моему опыту, особенно в Linux, DevMode очень быстрый (на самом деле, я в основном использую Mac в настоящее время, и он намного медленнее). Просто чтобы дать вам сопоставимую цифру: Перезагрузка официального учебника StockWatcher после внесения изменений в код занимает около одну секунду на моей машине с Linux. Даже с моим самым крупным проектом, который использует почти экстремальное количество виджетов на одной странице, время перезагрузки все еще очень хорошее.

Мне было бы очень интересно, в каких случаях вы видите медлительность: при перезагрузке страницы в браузере, при перезапуске сервера (кстати, почти всегда в этом нет необходимости), при повторном развертывании на стороне сервера (это можно сделать очень быстро, как объяснено здесь )? Одна вещь, которую я определенно рекомендую, это использовать оригинальную Sun / Oracle JVM вместо GCJ (которая часто используется по умолчанию в Linux). Также экспериментируйте с различными браузерами.

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

Да, все, что использует AJAX и JSON для передачи данных.

Какую модель выбрать для этого случая.

На самом деле официальный учебник StockWatcher должен быть относительно похож на то, что вы хотите делать, то есть в основном отображает часто обновляемые данные. Если ваши обновления поступают нерегулярно, вы можете рассмотреть возможность использования Comet для уменьшения количества запросов, но я бы начал с частых опросов (например, StockWatcher), а затем провел бы более точную настройку.

Перерисовка всего экрана, если добавлен новый элемент, становится интенсивнее ЦП по мере поступления новых обновлений.

UiBinder использует innerHTML вместо операций DOM для изменения пользовательского интерфейса и сочетает это с оптимизацией под конкретный браузер - так что это, вероятно, так же быстро, как и получается. Если производительность этих обновлений вас беспокоит, то GWT - действительно очень хороший выбор. Несколько дополнительных указателей, которые могут помочь, если ваш пользовательский интерфейс действительно замедляется, можно найти в «Что мне нужно сделать, чтобы ускорить медленное приложение GWT с помощью MVC» .

Вы не можете отобразить индексную позицию объекта элемента на его позицию в таблице-владельце без дополнительной обработки.

Это зависит от используемой вами модели. Может быть, спроектировать виджет (например, MyTable.ui.xml) вместе с вашим дизайнером, а затем реализовать соответствующую логику в ваших классах Java (не обязательно должен быть непосредственно в MyTable.java, если требуется сложное отображение). _{Если вам нужно решение для конкретной проблемы с этим отображением, вероятно, лучше было бы открыть отдельный вопрос.}