LINUX.ORG.RU

Клиентский GUI для базы данных.


0

0

Всем привет!

Какую среду разработки (язык, библиотеки, текстовый и GUI редактор) выбрать для создания subj?

В принципе нужно переписать часть приложений с Windows/Delphi, работающих с PostgreSQL через ODBC -- обычные программы, представляющие пользователям информацию из БД в виде таблиц, полей ввода, выпадающих списков, календариков, картинок, отчетов для печати и т.п. В итоге от проекта хочется получить кроссплатформенность (Linux-XWindow / M$ Windows) и красивый GUI. От среды разработки -- ОО язык программирования, архитектурную и концептуальную совершенность используемых API (навеяно кошмарами VCL ;) ), наличие высокоуровневых абстракций (типа визуальных DB-контролов в delphi) для сокращения времени разработки. К тому же хочется поиметь возможность в последствии прикрутить к базе еще и web-интерфейс, но при этом не писать для этого еще одно приложение снуля.

anonymous

Все кроме последнего (веба) тебе даст QT - и удобство программирования, и красоту гуи (выбирай любой - этих стилей - завались) и кроссплатформеность.
С вебом все не так.

anonymous
()

Да что больше по вкусу придётся - Tcl, Python, Ruby... И зачем обязательно ОО? ОО суксь паршивая...

Antichrist
()

Пока QT не устраивает по двум причинам (кстати, во многом по же, что и Delphi): отсутствием очевидного переносимого сервера приложений (это к вопросу о двух интерфейсах), и коммерческой лицензией весии для Windows (еще и платный компилятор M$VC требует). Опять же, как показал опыт работы с Делфи, компилируемые языки не очень удобны для программирования собственно GUI.

С tcl/tk уже приходилось иметь дело. Как язык для GUI части он хорош. Но целиком писать на нем клиентскую часть не возьмусь -- все-таки ужиться с его "все на свете есть строка" так и не удалось. Во всяком случае от языка, хочется чуть более строгого отношения к типизации. А тащить к клиенту еще и интерпретатор TCL только заради "чисто" GUI, имхо -- хамство. Опять же tk'шные виджеты выглядят страшно (даже если сравнивать с VCL -- юзеры этот выбор просто не поймут :) ). С другими биндингами не работал.

Сейчас смотрю в сторону Python. Вроде приятный язык и довольно шустрый. Но в Web готовых примеров реализации GUI-приложений для DB пока не нашел. Да, есть несколько разных библиотек доступа к БД, есть биндинги к разным GUI. С первого взгляда, ни какой "концептуальной целостности" во всем этом зоопарке в упор не вижу. Что из всего этого стоит выбрать, для избежания всяческого лишнего гимора, не понятно. Было бы заманчиво подергать из Python за Gnome2/Bonobo, но он опять же не переносим.

Ruby не видел. Какие возможности сдесь появятся для реализации subj'евой цели?

зы: Antichrist, афаик, формально, ОО является одиним из двух способов декомпозиции матрицы спецификации АТД, при котором акцент делается на генераторы. Штуку с таким суровым определением "паршивой суксью" надо называть очень аккуратно -- в отдельных случаях за наезды на ОО пасть порву. :)

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

Ламер (автор треда).

anonymous
()

У меня сейчас аналогичная проблема. Пока альтернативы delphi/kylix не вижу. :( А очень-бы хотелось.

UncleAndy ★★★
()

> Antichrist: Да что больше по вкусу придётся - Tcl, Python, Ruby.

Мне по вкусу больше Eiffel (design by contract и все такое). Но, являясь академическим интересом, в данном конкретном случае он не подходит. И вообще, проблема в том, что для изучения всего подряд нужно время (точнее -- годы :) ), а наиболее оптимальным решенем для этой конкретной заморочки будет только одним. Ведь задачка-то практически "типовая". Соответственно должно быть и "типовое" решение. Как Delphi, под Windows. Но куда копать при данных начальных условиях в задачке не знаю. ;(

Ламер.

anonymous
()

почему бы не выбрать Java? это хороший выбор. мы пользуемя и очень этим довольны, причем писали и на VC++/ATL/WTL и на BCC/QT и на C++Builder/VCL Alexey Visotski (admin_rsch@mail.ru)

anonymous
()
Ответ на: комментарий от anonymous

Tcl тащить с клиентом - вовсе не так страшно. Проверено. Тем более, что и Питона тащить пришлось бы.

Могу порекомендовать поиграть с Objective Caml - есть для него кой-какие весёлые решения (e.g., рисовалку простой гуйни к базам данных, с описанием самого UI на XML и отрисовкой через Tk, GTK+ и DTHML, я сделал за пару дней - кстати, на Питоне что-то вроде этого так же легде сделать можно).

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

Antichrist
()
Ответ на: комментарий от anonymous

Задача типовая. И примитивная. Но общего красивого решения - нет. Потому как вовсе не интересно этими вещами заниматься могучим computer scientist-ам. А лабухи чего только блин не напридумывают...

Из мощных теретических разработок разве что на WASH могу указать. И то, GUI туда ещё прилепить надо, там только DHTML...

Antichrist
()
Ответ на: комментарий от Antichrist

так вот и копаю сейчас в этом направлении.

anonymous
()
Ответ на: комментарий от Antichrist

так вот и копаю сейчас в этом направлении.

Ламер.

anonymous
()
Ответ на: комментарий от Antichrist

Скрипт питона можно можно конвертировать в испольняемый файл. Благо утилитки для этого существуют. А TCL либа все равно будет внешней приблудой. Не TCL -- нафик.

UI на XML.. Звучит заманчиво. Plsss... кинь ссылки на веселые решения для OCaml. И желательно, на исходники проектов, которые реализованы при помощи этого -- как показывает практика, имея под рукой хорошие примеры, в новом проще разбираться.

anonymous
()
Ответ на: комментарий от Antichrist

дак и subj не о science -- нужен реальный фреймворк.

Ламер.

anonymous
()
Ответ на: комментарий от anonymous

В качестве реального фреймворка - http://www.cduce.org/ - как фича для генерации собственно этих XML-ных гуёвин из базы данных (или чего угодно ещё). Пример рисовалки GUI был в пакете PXP. Свой собственный делается по мотивам за весьма недолго...

Antichrist
()
Ответ на: комментарий от Antichrist

Угу, имя этому фреймворку -- "напиши-все-сука-сам".

Мне нужно сделать GUI _для_ DB, а не _из_ DB. В DB описания GUI нет. Или ты знаешь способ формализовать процесс построения UI, требующий в качестве начальных условий лишь модель данных? ;)

Может, дейсвтительно, Java сдесь будет лучщим выбором? Тут и компоненты есть, и АПИ писаный с учетом design patterns, и средства разработки и биндинги к DB, и доступный application server и кроссплатформенность и... вот GUI только тормозной и памяти жрет много...

Ламер.

anonymous
()
Ответ на: комментарий от anonymous

Дык блин, модель данных - отправная точка для построения UI. Кроме того - кто мешает UI-формы хранить в самой БД? Это наиболее кошерный вэй.

Java - лучше и не связываться. Отвратнейшая технология, во всех отношениях. И, тоже, нет хороших готовых решений.

Antichrist
()
Ответ на: комментарий от Antichrist

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

Ламер.

anonymous
()
Ответ на: комментарий от anonymous

Неустраивает тем же, что и QT как таковой -- коммерческой лицензией под винду и использование в не-gpl проектах.

Ламер.

anonymous
()
Ответ на: комментарий от grustnoe

Да, это было бы удобно. Но средств, предоставляемых dhtml, (в данном случае) не достаточно для реализации морды клиента. Веб интерфейс нужен, в основном, для публикации в веб отчетов на основе данных из DB, в реальном времени. При этом хочется, чтобы веб-часть работала, повторно используя как можно больше компонентов основной части проекта: как минимум не залезая ниже уровня бизнес-логики.

Ламер.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.