Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Эта чуть более развернутая и удобочитаемая статья с подсветкой синтаксиса и подробным разбором перехвата NumberFormatException при перерисовке таблицы здесь. По мере необходимости статья будет дополняться и улучшаться.
WTF did I just read?!
в тегах есть упоминание mvc… так чего же вы объединяете все в одно?! сделали бы отдельный класс для хранения данных, не было бы никаких проблем с сериализацией… зачем сохранять полностью объект таблицы?!
в тегах есть упоминание mvc… так чего же вы объединяете все в одно?! сделали бы отдельный класс для хранения данных, не было бы никаких проблем с сериализацией… зачем сохранять полностью объект таблицы?!
… зачем сохранять полностью объект таблицы?!
Например, при перемещении/масштабировании пользователем колонок, сохранится декорирование.
На выходе получается бинарный файл.
Нет необходимости использовать базу данных и её драйвера.
Сохраняются все введенные данные, а значит при запуске программы не нужно в циклах заполнять и декорировать таблицу, так-как это происходит автоматически.
Например, при перемещении/масштабировании пользователем колонок, сохранится декорирование.
На выходе получается бинарный файл.
Нет необходимости использовать базу данных и её драйвера.
Сохраняются все введенные данные, а значит при запуске программы не нужно в циклах заполнять и декорировать таблицу, так-как это происходит автоматически.
Только есть одна проблема при сериализации Swing-компонентов, описанная прямо-таки в исходнике каждого J-компонента:
В общем, кратко говоря, ваши данные в таком виде могут неожиданно стать нечитаемыми при переходе на более новые версии Java. А возможность сериализации подобных компонентов добавлена лишь для кратковременного хранения/передачи компонентов между Java приложениями.
* Warning:
* Serialized objects of this class will not be compatible with
* future Swing releases. The current serialization support is
* appropriate for short term storage or RMI between applications running
* the same version of Swing. As of 1.4, support for long term storage
* of all JavaBeansTM
* has been added to thejava.beanspackage.
* Please see {@link java.beans.XMLEncoder}.
В общем, кратко говоря, ваши данные в таком виде могут неожиданно стать нечитаемыми при переходе на более новые версии Java. А возможность сериализации подобных компонентов добавлена лишь для кратковременного хранения/передачи компонентов между Java приложениями.
Тоже не понимаю зачем сериализовывать объект JTable.
Можно например сериализовать модели: TableModel и TableColumnModel
Можно например сериализовать модели: TableModel и TableColumnModel
По принципу китайских пионеров, сами придумали себе проблему, сами ее и решили :)
За страдания — плюс, но вообще так никогда не надо делать. Визуальное представление не должно быть перемешано с логикой хранения и загрузки данных, это совершенно излишняя связность. Неудивительно, что вы встретили столько проблем при реализации.
За страдания — плюс, но вообще так никогда не надо делать. Визуальное представление не должно быть перемешано с логикой хранения и загрузки данных, это совершенно излишняя связность. Неудивительно, что вы встретили столько проблем при реализации.
Большое спасибо за плюс и отзывы.
Хочу заметить, что в архиве, в папке «testTable\aosnec» было три файла:
testTable.java — здесь класс визуального представления,
JCTableCellRenderer.java — класс реализации прорисовки таблицы,
JColumnRenderer.java — класс прорисовки ярлыков колонок.
Да, в testTable реализованы методы создания или загрузки колонок и таблицы: loadColumn() и loadModel(). Их и вправду лучше реализовать в отдельном сериализованном классе. Честно говоря, изначально я так и делал, но код все равно не хотел работать из-за попыток сериализации выделения в таблице:
java.io.NotSerializableException: javax.swing.JTable$CellEditorRemover
По этому для простоты перемещения по коду я реализовал все вместе и создал маркеры TODO, чтобы проще было искать основные методы. Критику учел, поместил все в отдельный класс TableAndColumnCreater и переложил в архив.
Теперь в архиве, в папке «testTable\aosnec» четыре файла:
testTable.java — здесь класс визуального представления,
JCTableCellRenderer.java — класс реализации прорисовки таблицы,
JColumnRenderer.java — класс прорисовки ярлыков колонок,
TableAndColumnCreater.java — класс создания таблицы и колонок.
Все это можно скачать по вышеуказанной ссылке в статье.
Хочу заметить, что в архиве, в папке «testTable\aosnec» было три файла:
testTable.java — здесь класс визуального представления,
JCTableCellRenderer.java — класс реализации прорисовки таблицы,
JColumnRenderer.java — класс прорисовки ярлыков колонок.
Да, в testTable реализованы методы создания или загрузки колонок и таблицы: loadColumn() и loadModel(). Их и вправду лучше реализовать в отдельном сериализованном классе. Честно говоря, изначально я так и делал, но код все равно не хотел работать из-за попыток сериализации выделения в таблице:
java.io.NotSerializableException: javax.swing.JTable$CellEditorRemover
По этому для простоты перемещения по коду я реализовал все вместе и создал маркеры TODO, чтобы проще было искать основные методы. Критику учел, поместил все в отдельный класс TableAndColumnCreater и переложил в архив.
Теперь в архиве, в папке «testTable\aosnec» четыре файла:
testTable.java — здесь класс визуального представления,
JCTableCellRenderer.java — класс реализации прорисовки таблицы,
JColumnRenderer.java — класс прорисовки ярлыков колонок,
TableAndColumnCreater.java — класс создания таблицы и колонок.
Все это можно скачать по вышеуказанной ссылке в статье.
Я все понимаю, но сериализовать следовало данные, а не визуальный компонент-таблицу. А таблицу можно было просто научить корректно отрисовывать полученные данные (с позиционированием колонок, цветами и прочим).
При описанном вами подходе вы не сможете быстро и дешево изменить свое приложения, если требования к UI изменятся (скажем, если потребуется что-то, что таблицей не является, или будет целый набор связанных контролов, например добавится еще иерархическая структура, просмотр «мастер-детали» и т.п.).
При описанном вами подходе вы не сможете быстро и дешево изменить свое приложения, если требования к UI изменятся (скажем, если потребуется что-то, что таблицей не является, или будет целый набор связанных контролов, например добавится еще иерархическая структура, просмотр «мастер-детали» и т.п.).
Извините, промахнулся веткой. Отвечал на этот комментарий.
На счет необходимости сериализации данных можно долго спорить (по крайней мере баз данных или таблиц которые с ними работают). И такое я вряд ли буду сам практиковать, так-как это не только чревато порчей объектов в базах данных или самих таблиц и базы данных при транзакциях, но и грозит серьезными утечками памяти при количестве записей в базе больше сотни или двух. По этому сериализация хороша именно для маленьких приложений с табличным отображением данных, удобным для восприятия подавляющего большинства пользователей.
Но не могу не согласиться, что такой подход именно для таблиц может быть и впрямь излишен, как заметил выше knekrasov. Но ведь так хочется сериализовать сложные объектные структуры, содержащие визуальные элементы, и необходимые им уникальные данные. Особенно, такой подход ИМХО будет хорош для создания нодовых графических узлов (не содержащих в себе медиа контент). Извините, я живу, работаю и мыслю как дизайнер.
Но не могу не согласиться, что такой подход именно для таблиц может быть и впрямь излишен, как заметил выше knekrasov. Но ведь так хочется сериализовать сложные объектные структуры, содержащие визуальные элементы, и необходимые им уникальные данные. Особенно, такой подход ИМХО будет хорош для создания нодовых графических узлов (не содержащих в себе медиа контент). Извините, я живу, работаю и мыслю как дизайнер.
Видимо, вы действительно мыслите как дизайнер.
Все, что я пытаюсь донести — не перемешивайте несвязанные между собой задачи в одной сущности. Данные — отдельно, бизнес-логика — отдельно, представление — отдельно. Вы же зачем-то упомянули MVC в тегах?
Ваши доводы про «порчу таблиц при транзакциях» и про утечки памяти мягко говоря не обоснованы.
Все, что я пытаюсь донести — не перемешивайте несвязанные между собой задачи в одной сущности. Данные — отдельно, бизнес-логика — отдельно, представление — отдельно. Вы же зачем-то упомянули MVC в тегах?
Ваши доводы про «порчу таблиц при транзакциях» и про утечки памяти мягко говоря не обоснованы.
Вообще в своё время я подумывал о таком хранении данных из приложения (просто сливать сериализовать все нужные компоненты в файлы и потом считывать), но по весьма весомым причинам, приведённым выше, я ушёл от данного «брутального» способа хранения.
Вы правы, что помимо данных таблицы при такой сериализации сливаются ещё и:
— выделение в таблице
— все изменения размеров колонок
— сортировка колонок
и пр. мелочи.
Ну, что тут можно сказать, никто не мешает отдельно или даже вместе с данными хранить (и обновлять при изменении) информацию о выделении/колонках/сортировке. Мы именно так и поступили.
И ещё одна небольшая мелочь — мы решили уйти от стандартной сериализации объектов и стали широко использовать библиотеку XStream, которая умеет легко и быстро (а также с тонной опций) переводить сериализуемые объекты в читаемые XML файлы. Советую попробовать — останетесь довольны результатом.
P.S. Если интересно — могу более подробно описать XStream/наши варианты сохранения таблиц и пр. информации.
Вы правы, что помимо данных таблицы при такой сериализации сливаются ещё и:
— выделение в таблице
— все изменения размеров колонок
— сортировка колонок
и пр. мелочи.
Ну, что тут можно сказать, никто не мешает отдельно или даже вместе с данными хранить (и обновлять при изменении) информацию о выделении/колонках/сортировке. Мы именно так и поступили.
И ещё одна небольшая мелочь — мы решили уйти от стандартной сериализации объектов и стали широко использовать библиотеку XStream, которая умеет легко и быстро (а также с тонной опций) переводить сериализуемые объекты в читаемые XML файлы. Советую попробовать — останетесь довольны результатом.
P.S. Если интересно — могу более подробно описать XStream/наши варианты сохранения таблиц и пр. информации.
Слушайте, бросайте программирование, из этого все равно ничего путного не выйдет. Рисуйте лучше макеты, если вы дизайнер.
Ага. В 2001 году я уже послушал один раз совета не применять в интерфейсах программ разные цвета и градиентные переходы и (по тому же совету) пошел работать в дизайн наружной рекламы. Теперь жалею. Недавно заезжал на старую работу (ту, где создал первую программу с цветным графическим интерфейсом — «Калькулятор прихода/расхода») увидел её и почувствовал себя обманутым школьником… Те глянцевые, контрастные кнопки, меню и списки, которые сейчас применяются (в подавляющем большинстве) в дизайне интерфейсов программ меркнут перед этим, действительно рожденным в муках дизайном интерфейса. Хотя, на вкус и цвет…
Но я не живу прошлым.
Несколько лет назад, у меня появилась идея — объединить то, что сейчас все активно разделяют (код и графическое представление). Не в смысле вернуться к старому типу программирования, а создать визуальную архитектуру взаимодействия объектов (и графики, и логики, и данных). В общем, я пока еще экспериментирую «в песочнице» Java. Но скоро, чего нибудь придумаю. Конечно есть нодовая система представления и UML, но тут камнем преткновения является — удобочитаемость графического представления. Велосипед с формами давно устарел, как и общепринятые элементы графического интерфейса…
Уверен — в написании кода, именно за графикой будущее, так-как это убивает сразу всех зайцев: дешевле, красивее, понятнее. И то, над чем мы все сейчас трудимся — создание идеальных алгоритмов, вскоре достигнет уровня, когда таки и простая домохозяйка сможет набросать в три клика программку многоуровневого доступа к реляционным базам данных любимого магазинчика, с дисплея холодильника. И если вы её (домохозяйку) спросите о типе шаблона который она применяла при проектировании своей программы, то она вам не только скажет MVC, MVVM и/или др. типа «Фабрика», «Одиночка», «Наблюдатель» и т.д., но и картинками на дисплее того же холодильника покажет, как она это делает и какой эффект от этого получится при покупке товаров (или в каком магазине, какой шаблон используют). Хотя имена шаблонов к тому времени, наверное, тоже изменятся. Вот к этому мы все и стремимся. На том и будем стоять, и я, и создатели Java.
Но я не живу прошлым.
Несколько лет назад, у меня появилась идея — объединить то, что сейчас все активно разделяют (код и графическое представление). Не в смысле вернуться к старому типу программирования, а создать визуальную архитектуру взаимодействия объектов (и графики, и логики, и данных). В общем, я пока еще экспериментирую «в песочнице» Java. Но скоро, чего нибудь придумаю. Конечно есть нодовая система представления и UML, но тут камнем преткновения является — удобочитаемость графического представления. Велосипед с формами давно устарел, как и общепринятые элементы графического интерфейса…
Уверен — в написании кода, именно за графикой будущее, так-как это убивает сразу всех зайцев: дешевле, красивее, понятнее. И то, над чем мы все сейчас трудимся — создание идеальных алгоритмов, вскоре достигнет уровня, когда таки и простая домохозяйка сможет набросать в три клика программку многоуровневого доступа к реляционным базам данных любимого магазинчика, с дисплея холодильника. И если вы её (домохозяйку) спросите о типе шаблона который она применяла при проектировании своей программы, то она вам не только скажет MVC, MVVM и/или др. типа «Фабрика», «Одиночка», «Наблюдатель» и т.д., но и картинками на дисплее того же холодильника покажет, как она это делает и какой эффект от этого получится при покупке товаров (или в каком магазине, какой шаблон используют). Хотя имена шаблонов к тому времени, наверное, тоже изменятся. Вот к этому мы все и стремимся. На том и будем стоять, и я, и создатели Java.
Я же не писал, что плохо использовать разные цвета в интерфейсе. Я вам написал этот комментарий, потому, что вместо того, чтобы в чем-то разобраться, вы тупо копируете куски кода из интернет и ищете ответы на форумах (а надо — в мануалах и исходных кодах). Возможно, какую-то простую программку таким методом и можно написать, но если вы захотите сделать более серьезный проект, или работать в команде, этот подход в итоге провалится. Более того, такой подход, когда человек досконально не разбирается в используемых инструментах, чреват багами.
Но потом я еще подумал, мне кажется, что и с проектированием интерфейсов у вас не очень. Возьмем, например, скриншот таблицы, приведенный в конце статьи. Что мы видим, глядя на него? Бессмысленные иконки в заголовке каждой колонки. Часть иконок не узнаваема, часть непонятно что значит, зачем они поставлены тут, непонятно, видимо по принципу «чтобы были». Стоит ли говорить, что в данном случае вместо пользы (быстрое нахождение нужного элемента) иконки представляют собой визуальный мусор, отвлекающий и замедляющий анализ представленной информации? Возможно, автор не знает, зачем используются иконки и значки в интерфейсах и бездумно повторяет то, что увидел где-то в другом месте?
Кнопки сгруппированы внизу без всякого смысла и логики. Надписи в ячейках прилипают к разделительным линиям без всякого отступа. Сочетания красного и желтого цветов плохо читаемы.
А ведь все эти вещи уже давно изучены и описаны, мне кажется, вам стоило бы почитать не только книжки по Java, но и книжки на тему usability/ux design.
Что касается идеи «визуальной архитектуры» — а давайте, нарисуйте пару концептов, напишите статейку, хабрапользователи, уверен, с удовольствием ее обсудят и укажут вам на все недостатки. Хотя я конечно, сильно сомневаюсь, что описанное вами вообще возможно.
> создание идеальных алгоритмов, вскоре достигнет уровня, когда таки и простая домохозяйка сможет набросать в три клика программку многоуровневого доступа к реляционным базам данных любимого магазинчика, с дисплея холодильника
Не достигнет. Она бросит затею на попытке понять, что такое вообще реляционная база данных (если они все еще будут существовать).
Но потом я еще подумал, мне кажется, что и с проектированием интерфейсов у вас не очень. Возьмем, например, скриншот таблицы, приведенный в конце статьи. Что мы видим, глядя на него? Бессмысленные иконки в заголовке каждой колонки. Часть иконок не узнаваема, часть непонятно что значит, зачем они поставлены тут, непонятно, видимо по принципу «чтобы были». Стоит ли говорить, что в данном случае вместо пользы (быстрое нахождение нужного элемента) иконки представляют собой визуальный мусор, отвлекающий и замедляющий анализ представленной информации? Возможно, автор не знает, зачем используются иконки и значки в интерфейсах и бездумно повторяет то, что увидел где-то в другом месте?
Кнопки сгруппированы внизу без всякого смысла и логики. Надписи в ячейках прилипают к разделительным линиям без всякого отступа. Сочетания красного и желтого цветов плохо читаемы.
А ведь все эти вещи уже давно изучены и описаны, мне кажется, вам стоило бы почитать не только книжки по Java, но и книжки на тему usability/ux design.
Что касается идеи «визуальной архитектуры» — а давайте, нарисуйте пару концептов, напишите статейку, хабрапользователи, уверен, с удовольствием ее обсудят и укажут вам на все недостатки. Хотя я конечно, сильно сомневаюсь, что описанное вами вообще возможно.
> создание идеальных алгоритмов, вскоре достигнет уровня, когда таки и простая домохозяйка сможет набросать в три клика программку многоуровневого доступа к реляционным базам данных любимого магазинчика, с дисплея холодильника
Не достигнет. Она бросит затею на попытке понять, что такое вообще реляционная база данных (если они все еще будут существовать).
Я сдаюсь. Но… таблица выше, это всего лишь «пример» и дизайна в ней нет вообще (особенно моего). Это такая «глиняная» заготовка из которой можно слепить то, что нужно… Правда если руки растут из того места. То, что получится из этой «глины» вы скоро увидите, когда я закончу свою программу. Признаюсь по секрету, табличная форма представления (для меня) очень громоздка сама по себе. В общем, я над этим работаю. Но за критику и очень хорошие советы — большое спасибо.
Мне кажется компонент JTable можно использовать только для каких нибудь очень простых таблиц, потому что не очень он удобный.
Для более сложных таблиц можно использовать такой компонент как JxCell это таблица аля Excel.
Правда она платная.
Но зато в ней есть много фич как в Excel например формулы в ячейках и другое.
Для более сложных таблиц можно использовать такой компонент как JxCell это таблица аля Excel.
Правда она платная.
Но зато в ней есть много фич как в Excel например формулы в ячейках и другое.
Спасибо за ссылку, но я сторонник ОЧЕНЬ чистого API.
Такое легко получить в JTable, примеров много в сети Интернет, например вот или здесь.
Всего лишь, пишем пару малюсеньких классов дополнительных и все. А по формулах отдельный разговор, как я писал в своей статье здесь, это легко проверяется при перерисовке таблицы. Создаем свои «макро-функции» и все. Главное не использовать циклов, это часто вешает программу.
Такое легко получить в JTable, примеров много в сети Интернет, например вот или здесь.
Всего лишь, пишем пару малюсеньких классов дополнительных и все. А по формулах отдельный разговор, как я писал в своей статье здесь, это легко проверяется при перерисовке таблицы. Создаем свои «макро-функции» и все. Главное не использовать циклов, это часто вешает программу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JTable и Serializable или таблицы в Java и танцы с бубном при сохранении объектов в файлы