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

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

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

А как на питоне писать не ОО? я тупой?

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

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

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

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

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

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

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

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

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

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

Ламер.

может сразу писать веб-интерфейс? будет полная кроссплатформеность

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

На питоне? Никак. Это я просто удивляюсь, на фига ОО в обязательные требования угодило...

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

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

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

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

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

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

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

Ламер.

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

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

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

Ламер.

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

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

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

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

Ламер.

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

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

а чем собственно PyQt не вариант?

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

Ламер.

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

Ламер.

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

Ламер.

.NET