История изменений

Раскрою мысль немножко подробнее.

У подключения сторонних библиотек всегда есть и плюсы, и минусы. И принимать решения всегда надо по целесообразности, взвесив их.

Самый очевидный плюс – сокращение времени разработки. Ну и избыточность готовых решений увеличивает вероятность того, что потом не придётся допиливать ещё и библиотеки.

Минусы. Та самая избыточность, это ещё и избыточность кода. Далее, стороннюю библиотеку надо либо включать к себе, либо делать ссылку на сторонний репозиторий (submodule или ещё как-то). Разные версии Qt, ещё надо следить, как они сочетаются с разными версиями сторонней библиотеки. Это ещё одна точка отказа даже не столько для меня, сколько для мейнтейнера, который, возможно, будет это собирать под условную федору или альт.

Я представляю, что такое типичный генератор отчётов. Это дополнительная прослойка над БД, иногда ещё с визуальным помощником. Плюс разные форматы представления и разные форматы вывода. Довольно жирная штука.

С другой стороны, кутешные классы QText* – это, по сути и есть низкоуровневая часть библиотеки генерации отчётов (без прослойки), которые всю самую дурную часть работы берут на себя. Некоторые нестыковки, о которых я написал выше, огорчают, но всё это решаемо. Разница в сокращении работы между ними и готовым генератором отчётов для меня, боюсь, ну уж очень незначительна.

И для работы, где эти отчёты придётся клепать под сотню или даже больше, а квалификация у разработчиков разная – я первый посоветую взять тот же cutereport или его форк. Но у меня в текущем проекте отчётов будет не так много, и аккуратное низкоуровневое решение здесь для меня самое то. Напишу несколько функций-хелперов (часть уже написана), делов-то.

P.S. Вот для работы с zip-ами я взял готовую QuaZip. Там это действительно имело смысл.

Раскрою мысль немножко подробнее.

У подключения сторонних библиотек всегда есть и плюсы, и минусы. И принимать решения всегда надо по целесообразности, взвесив их.

Самый очевидный плюс – сокращение времени разработки. Ну и избыточность готовых решений увеличивает вероятность того, что потом не придётся допиливать ещё и библиотеки.

Минусы. Та самая избыточность, это ещё и избыточность кода. Далее, стороннюю библиотеку надо либо включать к себе, либо делать ссылку на сторонний репозиторий (submodule или ещё как-то). Разные версии Qt, ещё надо следить, как они сочетаются с разными версиями сторонней библиотеки. Это ещё одна точка отказа даже не столько для меня, сколько для мейнтейнера, который, возможно, будет это собирать под условную федору или альт.

Я представляю, что такое типичный генератор отчётов. Это дополнительная прослойка над БД, иногда ещё с визуальным помощником. Плюс разные форматы представления и разные форматы вывода.

С другой стороны, кутешные классы QText* – это, по сути и есть низкоуровневая часть библиотеки генерации отчётов (без прослойки), которые всю самую дурную часть работы берут на себя. Некоторые нестыковки, о которых я написал выше, огорчают, но всё это решаемо. Разница в сокращении работы между ними и готовым генератором отчётов для меня, боюсь, ну уж очень незначительна.

И для работы, где эти отчёты придётся клепать под сотню или даже больше, а квалификация у разработчиков разная – я первый посоветую взять тот же cutereport или его форк. Но у меня в текущем проекте отчётов будет не так много, и аккуратное низкоуровневое решение здесь для меня самое то. Напишу несколько функций-хелперов (часть уже написана), делов-то.

P.S. Вот для работы с zip-ами я взял готовую QuaZip. Там это действительно имело смысл.

Раскрою мысль немножко подробнее.

У подключения сторонних библиотек всегда есть и плюсы, и минусы. И принимать решения всегда надо по целесообразности, взвесив их.

Самый очевидный плюс – сокращение времени разработки. Ну и избыточность готовых решений увеличивает вероятность того, что потом не придётся допиливать ещё и библиотеки.

Минусы. Та самая избыточность, это ещё и избыточность кода. Далее, стороннюю библиотеку надо либо включать к себе, либо делать ссылку на сторонний репозиторий (submodule или ещё как-то). Разные версии Qt, ещё надо следить, как они сочетаются с разными версиями сторонней библиотеки. Это ещё одна точка отказа даже не столько для меня, сколько для мейнтейнера, который, возможно, будет это собирать под условную федору или альт.

Я представляю, что такое типичный генератор отчётов. Это дополнительная прослойка над БД, иногда ещё с визуальным помощником. Плюс разные форматы представления и разные форматы вывода.

С другой стороны, кутешные классы QText* – это, по сути и есть низкоуровневая часть библиотеки генерации отчётов (без прослойки), которые всю самую дурную часть работы берут на себя. Некоторые нестыковки, о которых я написал выше, огорчают, но всё это решаемо.

И для работы, где эти отчёты придётся клепать под сотню или даже больше, а квалификация у разработчиков разная – я первый посоветую взять тот же cutereport или его форк. Но у меня в текущем проекте отчётов будет не так много, и аккуратное низкоуровневое решение здесь для меня самое то. Напишу несколько функций-хелперов (часть уже написана), делов-то.

P.S. Вот для работы с zip-ами я взял готовую QuaZip. Там это действительно имело смысл.

Раскрою мысль немножко подробнее.

У подключения сторонних библиотек всегда есть и плюсы, и минусы. И принимать решения всегда надо по целесообразности, взвесив их.

Самый очевидный плюс – сокращение времени разработки. Ну и избыточность готовых решений увеличивает вероятность того, что потом не придётся допиливать ещё и библиотеки.

Минусы. Та самая избыточность, это ещё и избыточность кода. Далее, стороннюю библиотеку надо либо включать к себе, либо делать ссылку на сторонний репозиторий (submodule или ещё как-то). Разные версии Qt, ещё надо следить, как они сочетаются с разными версиями сторонней библиотеки. Это ещё одна точка отказа даже не столько для меня, сколько для мейнтейнера, который, возможно, будет это собирать под условную федору или альт.

Я представляю, что такое типичный генератор отчётов. Это дополнительная прослойка над БД, иногда ещё с визуальным помощником. Плюс разные форматы представления и разные форматы вывода.

С другой стороны, кутешные классы QText* – это, по сути и есть низкоуровневая часть библиотеки генерации отчётов (без прослойки), которые всю самую дурную часть работы берут на себя. Некоторые нестыковки, о которых я написал выше, огорчают, но всё это решаемо.

И для работы, где эти отчёты придётся клепать под сотню или даже больше, а квалификация у разработчиков разная – я первый посоветую взять тот же cutereport или его форк. Но у меня в текущем проекте отчётов будет не так много, и аккуратное низкоуровневое решение здесь для меня самое то. Напишу несколько функций-хелперов (часть уже написана), делов-то.