softwarer grexhideВ целом - пластинка эта (о гридокидании) уже довольно заезжена.
Дык другой-то нет. Действует принцип "возьми то, чего не умеешь, и объяви неумение этого достоинством, это позволит увести разговор в сторону". Точно так же мы много лет выслушивали, что версионность не только не нужна, но даже вредна.

Дельфистам предложение:

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

Итак, вы берете за компонент-предок TDBGrid или его предка. Я беру JTable. Субклассировать вам TDataSource и TDataSet можно как угодно. Я соответственно беру AbstractTableModel или мой субкласс от него.

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

Итак, перчатка брошена. Понеслись.

grexhide
Покупаем DevExpress Quantum Grid и не пудрим себе мозги. Цена вопроса - четыре дня работы программиста (цена продукта и срок "платежа/доставки")

А как только уважаемый "перчаточный дуэлянт на велосипеде" самостоятельно реализует функционал, подобный DevExpress хоть в 20-30% их функционала (не забыв, естественно, про адекватный DataBinding, с возможностью хоть какого плагина в Eclipse), и желательно - на SWT/Swing по выбору - милости просим об этом уведомить сообщество.


DataBinding? А зачем? В наследнике от грида получить данные из SelectionModel и вытащить соответствующий элемент живущей в модели коллекции - не более 5-10 строк кода. Точно так же для не-гридовых контролов, сделать в модели коллекцию интерфейсов, реализованных в наследниках от JEdit и прочих контролов - тоже 5-10 строк. Реализовать FieldByName для элемента коллекции строк - также весьма тривиальная задача, включая перегрузку методов get/set для разных типов данных.
На написание фильтрации в гриде - ушло 4 часа, включая поиск кое-каких идеек на koders.com (оттуда почерпнута идея поместить контролы фильтрации не в заголовки а в нулевую строку). Фиксированные столбцы в моем гриде есть, группировка заголовков - есть. Нет группировки строк по выбранным полям, как в девэкспрессе, и нет сортировки по щелчку на столбце (встроенный гридовый сортировщик JDK6 меня не устраивает по ряду причин, если в ближайших билдах шестерки поведение сортировщика не поменяется - напишу свой).
Объем кода реализующего фильтрацию в гриде - 7 килобайт. Реализованный набор функционала меня полностью устраивает, если понадобятся дополнительные фичи - допишу.
Кстати насчет "плагина в Eclipse" - нету у меня эклипса... стер я его... netbeans удобнее :)

grexhide
То, что ув. г-н Козлов не напишет свой DevExpress подобный framework и за пять и за двадцать пять человеко-лет, это очевидно (впрочем, и объективно).


А я и не гонюсь за всем функционалом. Мне достаточно такого набора как в EhGrid, но при условии управляемости кода.

grexhide
Покупаем DevExpress Quantum Grid и не пудрим себе мозги. Цена вопроса - четыре дня работы программиста (цена продукта и срок "платежа/доставки")


Анекдот: новый русский с сыном идут по берегу моря и видят художника за мольбертом. НР наставительно говорит сыну: "видишь, у него нет полароида, и он мучается"
:)

pamir
Раскрыт секрет программистов Java! Они не программируют. Они искусством занимаются. "Картины" рисуют.
Это, конечно, дольше и более трудоемко, но зато глядя на код видишь внутреннюю красоту
:))

Это... а книжка Кнута почему-то называется "Искусство программирования" а не "К вопросу об оптимальных траекториях движения мыши при применении RAD Drag-n-Drop" :) Ну что поделаешь - консервативный был дед...

Plafкоторые они конструируют в своем графическом редакторе.

Обозвать дельфю графическим редактором - это жестоко ))

grexhide
Господа, я задал конкретный вопрос (по поводу примера целостного технологического RCP стека, подобного технологиям Delphi и Oracle)


А где ты в Delphi увидел "целостный технологический RCP стек"? Насчет Оракла - судить не берусь, к ихнему серверу баз данным я отношусь с большим уважением, а насчет клиентских платформ - особой радости при мысли о смене Билла Гейтса на Ларри Эллисона не испытываю.
Если нужен RCP который позволяет вести разработку "сам-в-себя" - посмотри в сторону Netbeans Platform (да и вообще полного пакета NetBeans 5.5 - это решение типа "всё-в-одном-флаконе-открывай-и-наливай").

Хотя применение готовых RCP-платформ - опять же штука ограничивающая. Тот же NBP - отличное решение для типового круга задач, но шагнуть за пределы органичений архитектуры тяжелее (хотя и возможно) чем при написании своего фреймворка.

grexhide
Если мне нужно.. банально... поесть, то я иду или в ресторан, или в магазин. Где покупаю готовое блюдо или продукт-полуфабрикат (соответственно) нужного мне качества и степени готовности.
И у меня как-то не возникает комплекса на том месте, что я не могу и не должен для этого брать ружье, сеть или копье, ломиться на природу, выслеживать дичь, собственноручно ей забивать, свежевать, разводить костёр и пр. (хотя иногда - и это тоже, является, неплохим развлечением, в виде исключения, разумеется).


Пример не совсем корректен. Вот когда я окончательно распрощаюсь с остатками здравого смысла и решу написать собственную виртуальную машину, собственный аналог swing-а и собственное IDE под это всё - тогда да, это уже и изготовлением копья из срубленного дерева и подобранных на берегу кусков кремня запахнет...
Но - если задачу можно адекватно решить без привлечения дополнительных сущностей, лучше ее решать без привлечения дополнительных сущностей.

Имея набор базовых элементов, предлагаемых явой/свингом, можно в конечные сроки изготовить из них требуемые компоненты интерфейса с требуемым функционалом. Да, тот же DevExpress предлагает более богатый функционал и позволяет минимизировать затраты времени на разработку приложения. Да, применение готовых компонентов позволяет больше времени уделить собственно бизнес-процессам ради которых пишется приложение, а не фреймворку. Но не надо забывать о том что есть еще такая вещь как code maintainability. Всё-таки готовые приложения - это фастфуд. Можно и несварение кишечника получить (каждый релиз DevExpress VCL, выходящий ежемесячно, сопровождается очень немаленьким набором багофиксов).

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

alexx7262Vladimir Kozlov

"DataBinding? А зачем? В наследнике от грида получить данные из SelectionModel и вытащить соответствующий элемент живущей в модели коллекции - не более 5-10 строк кода. Точно так же для не-гридовых контролов, сделать в модели коллекцию интерфейсов, реализованных в наследниках от JEdit и прочих контролов - тоже 5-10 строк. Реализовать FieldByName для элемента коллекции строк - также весьма тривиальная задача, включая перегрузку методов get/set для разных типов данных."

наповал )))

А я всё думаю - почему это в Java нет DataSet?
Все ж так просто...

Там еще и DataSource нет. Еще раз - весь функционал датасета строится вокруг TableModel. У TableModel есть fireXXXX, у грида - SelectionModel. Этого достаточно.

alexx726Положительные эмоции оставили JGoodies, Skin LookAndFeel (от команды L2FProd), Borland и Substance. Учитывая большое кол-во тем, пользователю должно покатить. Единственное, Substance немного тормозит (очень уж "навернули" они). Ну, ораклевый еще можно (хотя он своеобразный)

Остальными (вроде и симпатичными) пользоваться стремно после JDK 1.5 (по крайней мере, у меня после переключения между LnF начинаются проблемы)

Не все LnF одинаково полезны. На мой вкус - Tonic оптимальный выбор, ведь LnF нужен не только для изготовления красивых скриншотов, но и для того чтоб смотрящий в приложение по 8 часов в день пользователь к вечеру не начинал тереть покрасневшие глаза.
Один из показательнейших в этом отношении примеров - Eyeon Digital Fusion. Проработка интерфейса - на твердую пятерку. Ну или SoftImage XSI. Оба этих продукта предназначены для людей которые не тарабанят вслепую по цифровой клавиатуре, а очень неслабо напрягают зрение в процессе работы, и интерфейсы в них отполированы до совершенства, чтобы снизить ненужные напряжения до минимума.