IT-redneck

Так вот, судя по комментариям там, там ад и ханука, мейнстрима программистского просто нет.

From:

mr-st.livejournal.com

Ну почему, судя по комментам в мэйнстрим таки .NET и Java попадают. А вот для UI, будь то web или десктоп, зоопарк действительно хороший.

From:

Судя по комментариям, есть три типа программеров: новаторы, попробовать буззворды; консерваторы, советуют что сами последние 5 лет используют; и фантасты, которые "мыслят глобально" и Вещают про гугол.

From:

Не, не в этом дело. Дело именно в херовых моделях.
Если в борланде в 1995 году (!) замечательно спроектировали датагрид, то этого не отнимешь. Но почему-то почти блин 15 лет все, все изобретают свои велосипеды и не хотят проанализировать, что же сделано ДО них и перенять позитивный опыт.
Если у меня на том же QT с выстраиванием модели одна всего лишь табличка (грид базы данных) - это МОДУЛЬ, целиком. Чисто модуль реализующий этот функционал, хард, так сказать, кодед. Но ведь это же ненормально, хоть мне пусть на эту тему гики сцут в вочи.

From:

Чисто модуль реализующий этот функционал, хард, так сказать, кодед. Но ведь это же ненормально, хоть мне пусть на эту тему гики сцут в вочи.
Там ООП. Наследуйся, переопределяй функции. Модель qtшная очень минималистично выражается через виртуальные методы (шесть виртуальных + десяток ролей досконально описывают все возможные модели, не только таблицы).

From:

В дельфи и дотнете тоже ООП, тоже виртуальные методы. Но вот работать удобнее с дельфийской архитектурой, дотнетовская(которая вообще ближе к qt) - ад кромешный.

From:

Дотнет - это крайне плохой, не годный ООП.
Я конкретно про Qt высказывался, и средства контроля изменчивости в ней.

From:

Дотнет сам по себе лучше Qt+moc
А вот библиотека его и контролы типа гридов - какой-то индусский ад, в плане архитектуры.
Насчет qt - надо пробовать, не видел.

From:

"Дотнет сам по себе лучше Qt+moc" чем именно он лучше? Непрозрачностью?

А вот библиотека его и контролы типа гридов - какой-то индусский ад, в плане архитектуры.
Насчет qt - надо пробовать, не видел.
Ясно. Не ел, но осуждаю, ага.

From:

Вот о чем и речь. А модель борландовская - это те же виртуальные методы плюс идеология пропертей. Хочешь, достаточно тебе - назначь проперти и получи функциональны грид (это делает собственно штатным образом сам дизайней формы). Ширины колонок, цвета и т.п. - все есть в пропертях. Мало? Перекрой, унаследуйся и дальше как в qt. Я ж еще раз говорю - в qt все теоретически классно, но... долго :)

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

From:

Это у тебя сплошное словоблудие.
В студию пример, который "делать дорого".
Проперти в qt есть, если что.

From:

Дык я именно про это и говорю, что придется делать самостоятельно.
Допустим, есть проект, в нем три десятка отображаемых таблиц, под каждой из которых будет своя модель.
У меня есть под это какие-то метаданные, как должна выглядеть таблица.
И есть метод. как я могу эти таблицы рисовать в qt - а именно вариацией на тему перекрытия, допустим, QSqlQueryModel::data, расписывая там все внутри по ролям.
То есть все равно нужно создавать реализацию для этого дела, обобщенную, чтобы я мог из метаданных загрузить вид таблицы в зависимости от случая, эта моя перекрытая модель бы это дело рассосала и показала бы мне таблицу как положено.
А речь о том, что можно было бы сделать для 99% случаев такой функционал внутри модели, ну или обозвать ее там пусть QSqlQueryModelMostUsed, и для подавляющей массы случаев этого бы хватило выше крыши.

Или я не понял твоего вопроса? :)
ЗЫ проперти qt тут ни при чем

From:

Я не понял твоей проблемы.
Нахера ты вручную делаешь модели для таблиц?
Бери QSqlMode, наворачивай поверх QSortFilterProxy - и получай profit.

From:

Я про базовые желание при реализации таблиц сделать такие-то капшыны в заголовках, таким-то цветом. таким=то шрифтом и т.п.
В какой последовательности ты такие типовые задачи решаешь?

From:

Ёлы палы!
Капшены:
http://doc.trolltech.com/4.5/qsqltablemodel.html
QSqlTableModel *model = new QSqlTableModel;
//...
model->setHeaderData(0, Qt::Horizontal, tr("Name"));
model->setHeaderData(1, Qt::Horizontal, tr("Salary"));
Нужно вечно задавать цвет и шрифт?
Настрой стиль на application глобально.
Нужно лишь для некоторых?
Ищи в документацию в QWidget setBackgroundRole/setForegroundRole, либо пронаследуйся от QSqlTableModel один раз, определи всё по рялом, вытащи нужные тебе параметры в Property, и юзай свой один раз написанный класс для моделей.

Мне что, рассказывать ребе как на базе библиотеки построить четыре штуки удобных и нужных именно им контролов?

From:

либо пронаследуйся от QSqlTableModel один раз, определи всё по рялом, вытащи нужные тебе параметры в Property, и юзай свой один раз написанный класс для моделей.

Вот именно про это я и писал и именно так и делал :)

Речь шла не об этом. А о том, что на мою точку зрения, имея за горами 2009 год и вагон чужого опыта в лице MS-Borland можно было бы придумать "в базовой поставке" средства поприятнее. Например, в упомянутых продуктах есть почти что интерактивные средства дизайна таблиц, сопоставление типа "имя поля из базы - колонка - параметры". Почему такое хотя бы было не повторить кроме как по причинам религиозным - я ума не приложу, то что это неудобно - не поверю, ибо скорость опять таки разработки увеличивается в разы. Да, я понимаю, что

zabivator сделает обертку и получит то что хочет, но вот это и есть тот самый входной порог. А 99% программистов "опердней" пойдет на вижуал бейсик или еще куда...
Короче, философия :)

From:

Ребята, ваша критика просто смешна.
Qt - библиотека общего назначения, она достаточно гибка и расширяема.
Вас не устраивает, что нужно написать порядка десятка кастомных контролов? Это вздор.

Нету времени? Ребята, у меня есть предложение - я вам напишу и доработаю эти контролы по вашим требованиям по цене 10 баксов в час (стандартная такса). Деньги за результат, а не за время. Идёт?

From:

Ну вот таки и зочем ви травете и сгазу переходите на тему шекелей? :)

From:

Я рейт обозначил.
Вам попиздеть как всё хуёво, или работать надо? Брюзжать и я могу.
А то ишь, не нравится им что нету виджета "бухгалтерский отчёт для БР".

From:

*QSqlModel

From:

> Основная проблема при переходе с используемых платформ на новые - это то, что "все нужно переделывать".

Проблема ли это? РФ-РБ переползла с технологий и потребления СССР на общеевропейское, за каких-то 10 считай лет. Очень много старого выбросили и заменили новым. И ничего. Рутина.

> Не так работают дата-гриды, не та модель работы с данными

Это есть. Но в целом тот Дельфи паттерн Table Gateway и был уродлив.
Сдох -- и хорошо.

> что использовать в качестве генератора отчетов

Ну даёте. Аксесс, конечно! :)
У МС есть крайне мощный репорт сервер.

> что выбрать, чтобы перейти с наименьшим напрягом, чтобы были библиотеки, чтобы потом было где искать разработчиков, и чтобы это не остановило всю работу

В этой задаче хорошо бы подошли типа профсоюзов или профобъединений. Типа "союз пчеловодов нижней Саксонии". Ваша ниша узкая, и Вы похоже оторваны от коллег. А в других нишах всё проще, обычно есть типовые технологии.

Если считаете, что нет библиотек -- а как тогда зарубежные товарищи аналоги делают? Если технология реально устарела -- может и хрен с ним. Зачем RS232 если вовсю USB и bluetooth.

From:

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

Access у клиентов может банально не быть. MSSQL с его репортинг сервисес тоже. Тут и так софт за собой тянет какую-то гору зависимостей, постоянно у клиентов то MDAC обновлять приходится, то дотнет, то iis перенастраивать.

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

А аналоги делаются просто. Самописанные библиотеки используются в основном. У нас в проекте есть железо с RS232, USB(HID), есть беспроводное с проприетарным приемником и протоколом, будет и блютуз вроде. Везде - только ручное написание, безальтернативно. "Никто такого больше не делает".

From:

> в дельфи, при отсутствии рефлекшена, ComponentModel, сборщика мусора - расширять Dataset и DBGrid намного проще - как-то более правильно спроектировано все

Думаю, мы говорим о разном. Я говорю о том, что доступ "под капотом" у датасета был через insert/post, было понятие "текущая запись". Это наследие DBF, в начале 90-х на нём и аналогах были написаны все "опердени". Уже в 1993, помнится, читал в компьютерных газетах стенания, что вот при переходе на Настоящие Сетевые БД С Настояшщим SQL всё это великолепие надо будет поломать. И вот, прошло всего лет 7, и всё поломали. )))

Вы говорите про design time -- да, реализовать банальный драг-н-дроп с кучей дельфийских фич из популярных никто не смог (хотя например в 2001 я лично писал веб-фреймворк на Ж2EE с хорошей интеграций ЖСП кода с неким сторажом -- да всё сдохло). Возможно, причина и в процессорах, тогда ява была медленная.

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

> Access у клиентов может банально не быть.

Есть у них специально для этого рантайм система. Тянется готовый экзешник с ДЛЛ и МДБ файлом, ничего не надо ставить, просто копируешь файлы. Для защиты от разбора там есть фича с паролем разработчика и вообще правами.

У меня есть книга про адвансед программирование на аксессе (на рус.), так это мегатул вообще. Почти дельфи, только компонент мало.

> А судя по комментариям - кто во что горазд.
> Везде - только ручное написание, безальтернативно. "Никто такого больше не делает".

Думаю, Вы не там смотрите. Во-первых ЖЖ всё таки не для профессионалов. Во-вторых, насчёт уникальности как-то не верю. В ЕС-Китае-США техникой занимается куча людей.

From:

Insert/post очень просто и прозрачно делается на sql-базах данных. В датасете просто указаны select, insert, update, delete-запросы и список первичных ключей.

Drag-drop дельфийский почти не нужен. Я им не пользуюсь уже лет 5, хотя половина кода на дельфи. Все что касается гридов и датасетов - генерится в рунтайме из метаданных базы.

From:

Это есть. Но в целом тот Дельфи паттерн Table Gateway и был уродлив.
Сдох -- и хорошо.

Может речь о модели с курсорной обработкой данных?

From:

да

From:

У курсорной обработки данных ноги росли из разных клипперов-фокспро. Факт, что целому поколеню программеров это сломало моск, бесповоротно :(

From:

ng67.livejournal.com

1C. Версия 8.2 Управляемое приложение.
Существовать будет долго, разработчики никуда не денутся...

From:

w00dy.livejournal.com

> непонятно, что использовать в качестве генератора отчетов

Для создания шаблонов отчётов кошерно пользовать Word, для него (2007-го) написать плагинчик который даёт доступ к вашим внутреним элементам, которые можно вставлять в документ, а потом лёгкое движение руки, и шаблон превращается в готовый отчёт ;)

From:

Только не мой моск
Кто Вам сказал, что вообще у клиента будет ворд? :)
Вообще имхо завязка в коммерческой системе на коммерческие продукты третьих фирм которые "обычно стоят" - это неправильно.

From:

w00dy.livejournal.com

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

From: