GWT Grid

    Недавно на Хабре обсуждались таблицы, используемые в веб-интерфейсах учётных систем. Вдохновившись этой темой, мы решили выложить в открытый доступ исходные продуктивные коды своей таблицы: https://finbudgetgrid.googlecode.com

    Полноценное использование таблицы можно увидеть в нашем Сервисе бюджетирования Finbudget.com. Система полностью написана на Java GWT, работает в среде Google AppEngine. Поэтому и таблица написана на Java, используется GWT, и работает на Google AppEngine.
    Мы опубликовали не только исходные коды таблицы, но и демо-приложение, которое использует таблицу. Всё — в одном проекте (но в разных пакетах; думаю, что не запутаетесь:).
    Скомпилированное и развёрнутое демо-приложение доступно по адресу finbudgetgrid.appspot.com.
    Проект «заточен» под Eclipse. Для его компиляции после загрузки исходных кодов потребуется настроить процессинг аннотаций, как это описано на странице GWTP.
    Уверен, что проект поможет тем, кто изучает GWT или хочет его изучить быстрее освоиться с принципами его работы, да и вообще, создавать красивые и удобные приложения.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 16

      0
      Порадовало желание содавать простые решения для учетных систем ☺.

      А как насчет «создавать красивые и удобные приложения» для программистов: Насколько просто настроить такой грид под новую таблицу? Добавить новую колонку? Сделать шапку многоязычной? Есть ли врзможность выгрузить настройки таблицы (например ширину колонок) в какой-нибудь XML?
        0
        По-порядку:
        • Можно посмотреть наше «боевое» приложение: там множество разнообразных таблиц. То есть создать новую таблицу достаточно легко.
        • Как добавить новые столбцы? Смотрим в исходном коде на файл GridView.java: со строки 103 по 113 создаются 6 полей. Добавить новые — по аналогии.
        • Многоязычность — это свойство всех приложений, которые пишутся на GWT. Делается легко и многими способами.
        • Настройки таблицы можно выгружать и восстанавливать: в коде есть зачатки этой функциональности, но потребуются, очевидно, доработки.
          0
          Спасибо за исходники. Приятно видеть, что кто-то таки использует Cell widgets в боевом проеке. Как удалось убедить руководство не использовать всякие gwt-ext да smartGWT?
            0
            gwt-ext и smartGWT 1) медленнее и 2) плохо интегрируются на страницу с нативными контролами GWT. Этого было достаточно. Сначала, конечно, попробовали их :)
              0
              Ну контраргумент — с ними быстрее колбасить, а наши проекты все в интранете, потому всё грузится быстро, а потом вообще из кеша. Повезло вобщем вам :)
              А с GAE пользуетесь JDO или JPA? Какие были аргументы? Кеширование используете? На скольки уровнях если да?
                0
                GXT3 уже делают более правильно. Они умеют работать с UIBinder. И генерируют более ортимальный код. Хотя конечно, самый оптимальный получится на CellWidgets.
              0
              А вы можете демоверсию сделать двуязычной?
            0
            С GAE работаем на Objectify. JDO и JPA не используются в силу того, что они притянуты к GAE за уши и порождают большой оверхединг. Objectify автоматизирует кэширование за счёт аннотирования. Пользуемся им.
            Кэширование на сервере — дело Objectify, на клиенте кэшируем списки. В коде есть класс ListsManager: можно посмотреть как он это делает.
              0
              Симпотично у вас, а главное достаточно шустрый DOM, который можно навернуть до нужной красоты.
              А вот транспорт не особо приятный, все же пулять весь набор одномерным массивом как-то… есть же JSON. И запрос данных тоже, на мой вкус, слишком миниатюрен. Может просто я против гиперминимизации данных… Но чую огребетесь вы на этом. Экономия на битах до добра не доводит.
                +1
                Спасибо за доброе слово.
                В демо-примере мы не заморачивались красотой транспорта: если есть желание, становитесь контрибьютором.
                Биты не экономили. Не совсем понял в чём миниатюрность запроса. Поясните, пожалуйста.
                  +1
                  Запрос на получение данных от finbudgetgrid.appspot.com/dispatch/GetData

                  в Post видно:

                  7|0|7|http://finbudgetgrid.appspot.com/finbudgetgriddemo/|4BE165E7793F80BC7F914760A3BBE44A|com.gwtplatform.dispatch.shared.DispatchService|execute|java.lang.String/2004016611|com.gwtplatform.dispatch.shared.Action|finbudgetgriddemo.client.grid.GetDataAction/1094887940|1|2|3|4|2|5|6|0|7|50|

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

                  При этом ответ с данными — одномерный массив. Насколько я понял все передается одним махом, т.е. пэйджинг клиентский.

                  В общем на вкус и цвет. Просто отметил техническую часть.
                    +1
                    Вот здесь как раз Вы уловили то, чем GWT очень сильно отличается от низкоуровневого кодинга. В приведённом POST'е практически всё — сигнатуры :). Параметр — один: 50 (в самом конце), — столько записей запрашивается на сервере.
                    Смотрим на код: GetData.java — класс, в котором определяется структура отправляемых и принимаемых параметров. Если потребуется добавить новые отправляемые параметры, допишем их сюда же, например, так:
                    @In(2) String message;
                    Если потребуется вернуть что-то с сервера, допишем
                    Out(2) String responce;
                    При формировании запроса (смотрим на строку 119 в файле GridView.java) создаётся собственно объект, передаваемый на сервер с параметрами в прописанной очерёдности: new GetDataAction(recordsQty). Java, к слову, проверяет передаваемые типы уже на этапе компиляции.
                    В общем, тезис о плохой сопровождаемости не принимается :)
                0
                Очень бы хотелось услышать о работе реального приложения на GAE. Как оптимизировали под ресурсы? Сколько квот жрёт? Во сколько обходиться один пользователь по ресурсам?
                  0
                  При добавлении 100,000 записей оно немного умирает

                  Ошибка
                  Сервер вернул ошибку: (InternalError): script too large stack: cib([object Object], fileName: finbudgetgrid.appspot.com/finbudgetgriddemo/565AEE3F7C6E9A487A59D92F3B89AB62.cache.html lineNumber: 3679

                  Хабра-эффект?

                    +1
                    На сервере GAE JVM не хватало памяти периодически javax.servlet.ServletContext log: Exception while dispatching incoming RPC call java.lang.OutOfMemoryError: Java heap space. Когда это стало очевидным, проапргейдил VM на более мощную, и всё нормализовалось. А вот один инстанс VM не убил, он-то и порождал ошибки. Убил его в 15:30, с тех пор ошибок не было.
                    Но 100 тыс. записей добавил прикола ради, ибо для практического использования это смысла не имеет.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое