А где бы скачать компоненту... тьфу. :)

В общем появилась необходимость в TreeTable. Посмотрел реализацию SwingX. Очень похоже на то что описывалось на сайте Sun (уж не знаю что из них первоисточник). Однако необходимость субклассировать DefaultMutableTreeNode под конкретную модель не очень вдохновила.

В связи с этим есть следующие соображения - передавать в конструктор экземпляр наследника от AbstractTableModel, дабы дерево из него ячейки тягало, а для построения дерева субклассировать DefaultTreeTableModel, передать его конструктору строковые параметры KeyField, ParentField, DisplayField, RootValue (то есть имена полей/колонок по которым построится дерево, и корневое значение), и написать внутрё построители чайлдов. Тогда получается универсальный класс модели дерева, который строит представление на базе переданной ему модели таблицы.

Кто-то с подобным игрался?

marx_freedomна сайте Sun есть конечно очень интересная статья (3 части) про TreeTable, только вот в конце написаны "недоделки" - какие именно, точно не помню и посмотреть сейчас не успеваю, но явно чего-то нужного мне не хватало. я остановился на использовании компонента из SwingX, пусть и пришлось унаследоваться от DefaultMutableTreeNode.


Наследник DefaultMutableTreeNode там имеет три ключевых метода: getChildren, isLeaf, toString. Замечательно. Передадим в наследника DefaultTreeTableModel экземпляр AbstractTableModel, этот же экземпляр транзитом поедет в конструктор наследника DefaultMutableTreeNode. В нем - вектор хэшей, который представляет собственно датасет (каждый хэш - строка). В DefaultMutableTreeNode добавим экземпляр хэша (грубо говоря ссылки на строку датасета). Тогда в нашем наследнике DefaultMutableTreeNode, получается, есть _всё_ для реализации getChildren, isLeaf, toString, абсолютно независимой от структуры столбцов :)

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

В общем код который с классами работает, получился таким:

FXDTreeModel mdl = new FXDTreeModel(MyDatasetTableModel, stringKeyFieldName,stringParentFieldName,valueRootKey);
this.jXTreeTable1.setTreeTableModel(mdl);

это переменная часть кода которая подхватывает TableModel а вся логика дерева упрятана в класс и работает в зависимости от данных/метаданных датасета.

expp
в JFace stateless Provider'ы - ну гораздо красивее
swing в оцтой

А JFace и SWT могут работать с нетбинсовским дизайнером? Или дизайнеру пофиг, лишь бы BeanInfo был? У меня опыта работы с SWT - ноль. Только скриншоты видел :)

exppканешь не могут. или Swing или JFace. Просто дизайнеров Swingа я нипанимаю....

А в чем JFace интерфейсы конструировать? _Только_ в эклипсе? И где можно внятно почитать - чем таким JFace/SWT лучше чем свинг? C конкретными аргументами?

alexx726
Выбрал L2FProd PropertySheet (пока применение ограничивается реализацией Object и DB Inspector. Разумеется, несколько Display Fields не забабахаешь - а надо ли?).
А их "компонента" собственно и есть реализация AbstractTableModel.

Там напильником пилить и пилить...
Вот на картинке собственно то чего мне хотелось. Пока еще в процессе отладки/шлифовки. Зато кормится данными из моего датасета, который тоже которую неделю из-под напильника не вылазит.

Дилемма - для редакторов полей написать интерфейс CellEditorProvider или эвент OnCellEditorComponentNeeded ??? :) Мне это и в гриде нужно - я предусматриваю разные типы редакторов в одной и той же колонке в зависимости от данных в строке датасета...

alexx726Мне что-то реализация SwingSet не понравилась (уже не помню почему, что-то с ней было не так).


Бугага. Посмотрел я на скриншоты свингсета:

http://swingset.sourceforge.net/Example7.php

Господа прикалываюцца или всерьез? Если эдитор в ячейке подобно Ленину - вечно живой - в этом какой-то сакральный смысл?

alexx726Скажу по секрету - у меня тоже DataSet уже которую неделю из под напильника не вылазит )) Отсюда и злобность на Java...


"Пилите, Шура, пилите - они золотые!" (с) Паниковский

alexx726
Боюсь что ты неправильно вопрос задал (было упомянуто слово DisplayField, без множественного числа) -разумеется, тебе это "творение" не подходит.


В моём понимании - DisplayField это то что показывается собственно в узлах дерева (в моем скриншоте это код бухсчета). Остальное - это так, колонки приблудные... :)

alexx726
C "едиторами" я благо вопрос решил раз и навсегда для любого потомка моей JTable и editor'a - реализатора моего интерфейса (опять же - "равнокриво", но пока устраивает)


Как, если не секрет? Я вижу два подхода - или передавать конструктору указатель на интерфейс реализующий создание эдиторов, или когда понадобился эдитор бросать эвент и возвращать эдитор из листенера. А у тебя как сделано?

alexx726"Как, если не секрет? Я вижу два подхода - или передавать конструктору указатель на интерфейс реализующий создание эдиторов, или когда понадобился эдитор бросать эвент и возвращать эдитор из листенера. А у тебя как сделано?"

Ну насчет конечно разных "едиторов" в разных строчках я пожалуй погорячился
(я просто пока не знаю как мне это в рунтайме организовать, в смысле как это прописывать в DataSet :))

Мое мнение - из грида наружу должно торчать нечто, которое передает наружу через эвент или через вызов функции имя поля и данные в строке, и получает экземпляр контрола для текущей редактируемой ячейки. Это задача не модели а view/controller-а.
То есть на все столбцы в ColumnModel вешается некий объект, который отрабатывает getCellEditorComponent, из него дергает нечто что отдает ему нужный контрол (ну там же можно и кастомные рендеры присобачить). В результате - грид и модель пишутся один раз и про них забываем, а контролы когда в них возникнет надобность приедут из обработчика событий грида.

alexx726
Мне, скажем вариант "покажи мне в строчке 1 checkbox, а в строчке 2 ButtonEdit" пригодился до сих пор только один раз - в форме абстрактных аттрибутов чего-либо (а потом все-равно выяснилось, что нужна Custom форма :)). Так что в Java я этого делать не буду.


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

alexx726
А если нужен один и тот же компонент - то все разруливается на уровне lookupSQL. Правда, придется запрос обновлять при прорисовке - как это скажется на производительности?

Обновлять при прорисовке может не понадобиться - в setCellEditor передаешь объект, внутри которого живет датасет кэширующий данные. Объект соответственно extends AbstractCellEditor implements TableCellRenderer, TableCellEditor, ActionListener, в нем живет контрол создающийся в конструкторе и вылезающий наружу через getTableCellEditorComponent.

alexx726
Дык в том то все и дело - а если это разные варианты ComboBox? Ну разные у них DataSet'ы :)) Что, все сразу заполнить? А сколько их?
По mainDataSet пробежаца и выяснить?
Лениво да и формализуется муторно (как я объясню своему dataSetField какой брать - скриптом?)

Тогда попа. Ну не совсем попа - в основном датасете можно замутить OnCalcFields, чтобы каждый раз при перерисовке по базе не шоркаться а единожды для каждой потребовавшейся записи за значением сбегать и закэшировать, а для эдитора - завести какой-то хэштейбл в котором будет лежать пополняемый при необходимости набор датасетов. Если нужный лукапу датасет в хэштейбле присутствует - берем оттуда, если нет - создаем новый и пихаем в хэштейбл. Ну а "какой брать" - добавь LookupSQL в dataSetField :) (он же и ключом хэша может быть)

alexx726нее - я ж говорю, муторно...Ленивый я :)
Да и завязано уже все на единый Controller для всего столбца, ну его нафиг.
Уже и так путаца начинаю в своем DataSet - после TableController, InspectorController, FormController + привязки FixedColumns + SummaryFixedRows
и взаимодействия 4-х JTable совсем мозги разъежаются :) А еще бы Groupable Headers ко всему этому безобразию сделать...

Так что от таких "горячих" таблиц я лично откажусь

Groupable Headers - я взял сэмпл из инета и переколбасил его чтоб как в EhGrid-е поведение было. Правда на более чем одном уровне группировки не тестил (и работать не будет, не закладывал такой функционал, бо не надо мне).
Кстати поделись идеей как SummaryFixedRows сделал. Решение "в лоб" - увеличить результат getRowCount в модели и отслеживать getValueAt, но суммари будет скроллиться, а чтоб не скроллилось есть подозрение что JScrollPane перекрывать надо...

alexx726
Как сделал? Да по рабоче-крестьянски. Как учат :) Добавляешь новый ScrollPane к панельке с mainScroll, убираешь у него VerticalScrollBar, убираешь у mainScroll HorizontalScrollBar и синхронизуешь HorizontalScrollBar новенького гаденыша с основным. Ежель нужен код - то завтра, на работе. Геморрой разумеется есть с fixedColumns (но это решается, хотя и крышу малость повело от синхронизации). Сами значения Summary храню в Field'е и пересчитываю при всяческих изменениях (поддерживаю пока только COUNT, SUM, AVG, MIN, MAX, CONSTANT - типа текст "Итого:")

Ой. и в том скроллпане еще один тейбл?

На случай если у тебя под фикседколумнс тоже отдельный тейбл - похвастаюсь: у меня фиксированные и горизонтально-прокручиваемые колонки в одном тейбле. Автор идеи - какой-то не то индус не то японец, правда в его реализации был полный бардак с убиванием эдитора после редактирования, так что код пришлось перетрясти слегка.

alexx726вот-вот
Кстати, хороший вопрос для обсуждения - наличие 4-х Tables вместо одной :)
Я пока встретил только плохую и очень плохую реализации. Думаю, что и первоисточник у нас с тобой один :) Только когда я вижу paint() с вызовом getRowcount(), я плачу

Похоже что да, первоисточник один. Во всяком случае paint() с вызовом getRowcount() там присутствует. Кстати, покажи код editingStopped из твоего варианта - там в первоисточнике один очень сомнительный кусочек кода, интересно глянуть что ты с ним сделал :) А то у меня большое подозрение что там вкопана мина в виде Invalid Cast Exception...