Здорово. Жалко, однако, что держите это все в секрете. Информационные технологии должны служить людям (большому количеству людей). Мне Google таблицы в этом отношении понравились гибкостью и простым совместным доступом. Но, соглашусь, что более сложное устройство более специфично.
Думаю, можно попробовать считать общую сумму в SUMIFS с указанием (<>) категорий по которым не нужно считать. Разделять записи по категориям так утомительно. Хотя, конечно, специфические задачи требуют специфических решений.
Хорошо. Я понял. Никогда не поздно исправиться, поэтому давайте обсудим это сейчас. Вне всякого сомнения, эта заметка подобна короткому сообщению или твиту и смысл её, как отмечено в комментариях "qml позволяет разрабатывать интерфейс очень быстро, qml рулит", поэтому возможно её стоит переименовать в "qml: могущество и простота. Часть 1-ая. Смысловая", а все технические подробности продолжить в статье "qml: могущество и простота. Часть 2-ая. Техническая". Но пока ограничимся этим комментарием.
Почему сделали такой выбор? Одним из наиболее значимых факторов в выборе того или иного инструмента является полнота знания — умение им пользоваться. Особенно важен этот фактор когда мы говорим о скоростных характеристиках разработки. Другой момент, что в qt вшит мощный механизм model/view, который я не знаю как можно было бы реализовать при помощи связки php+html/css/js или что тоже python+html/css/js, о которых говорилось в комментариях выше. Возможно постраничный вывод? Но зачем? В противном случае все перенесется в код на js + jquery (или подобные технологии). Java в этом смысле обладают с qt похожими возможностями, но ввиду того, что с java знаком чуть хуже выбор склонился в сторону qt.
С какими сложностями столкнулись? Ввиду того что задача была понятна, а инструменты хорошо известны трудностей практически не возникло. За исключением пожалуй совета придерживаться более четной нотации в именовании объектов и переменных в коде на qml (js), поскольку неакуратность в этом отношении может приводить к непредсказуемым результатам.
Почему приняли именно такие решения в процессе разработки? Поскольку в качестве источника данных выбрали базу данных, использование model/view было естественным продолжением этого решения, а благодаря мощной поддержке моделей в коде на qml, код отвечающий за интерфейс оказался очень компактным, практически таким же как если бы мы определяли шаблон для генерации html страницы.
Я полагал, что хабр это место где разработчики (и другие люди связанные с разработкой ) могут обмениваться опытом и мнениями. Пока я человек новый и пробую себя в различных жанрах. Этот часть моего обучения. Вы можете указать какого рода бы статьи Вам хотелось видеть — это будет ценно для меня. Критика мало конструктивная.
Выборка из базы осуществляется в классе MobyGamesItemsModel (260 строк кода). Возможно вы имели ввиду размер exe файла + библиотеки?
В любом случае, буду рад решению на php (люблю это язык), и читателям, думаю, оно будет полезно.
Код получился достаточно коротким и простым (если не сказать), поэтому не хотел захламлять место. Все же основная идея статьи то, что при помощи qml можно разрабатывать UI быстро (очень быстро), а если верить QtCompany, то после выхода Qt Design Studio 1.0 практически молниеносно.
P.S. Спасибо, что посмотрели код. setContextProperty использовали вместо qmlRegisterType по той причине, что модель в нашем случае не является тиражируемой сущностью, а единичным объектом к которому нужно получить доступ из кода на qml. Так что mobyGamesModel это просто связующее звено между моделью на С++ и кодом на java script.
В данном случае, с технической точки зрения особенно и нечего обсуждать, поскольку благодаря декларативному стилю описания интерфейса в qml все получилось очень быстро и просто, чем мне и хотелось поделиться. Сожалею, что Вас расстроил. любом случае спасибо. Мне важно знать мнения читателей, для написания будущих статей.
Вне всякого сомнения. Мы говорим про разработку на прикладных языках высокого уровня, поэтому какой бы инструмент мы не взяли будет frontend, backend и т.д., где-то это интерпретатор + скрипт, где то виртуальная машина + код. В случае Java это VM+код на Java, в варианте Qt это код на С + java script, и т.д. Думаю нет смысла искать ответ на эзотерический вопрос «что является лучшим всегда везде и при всех обстоятельствах?», поскольку каждый будет ратовать за свой любимый фраймворк. В данном случае выбор пал на Qt, поскольку мы его хорошо знали и qml, поскольку он предоставляет удобный декларативный интерфейс описания интерфейса. Все всякого сомнения данную задачу можно решить и при помощи других инструментальных и языковых средств. Целью же данной статьи было поделиться радостью и удивлением от того насколько быстро этого удалось достичь, сравнительно небольшим объемом кода.
Мы сосредоточились на скорости достижения нужной функциональности. В плане эстетики, мы остановились тогда, когда это стало достаточно наглядно и удобно (для нас). Но если вы предложите улучшения и наведете большую красоту будем Вам благодарны.
PHP нет, потому что нужен сервер для его отработки. А Java vs QML — можно использовать то, что нравиться и что больше знаешь, хотя у QML есть свои особые бонусы при разработке. Вот хорошая статья на эту тему.
Здорово. Жалко, однако, что держите это все в секрете. Информационные технологии должны служить людям (большому количеству людей). Мне Google таблицы в этом отношении понравились гибкостью и простым совместным доступом. Но, соглашусь, что более сложное устройство более специфично.
Хорошо. Я понял. Никогда не поздно исправиться, поэтому давайте обсудим это сейчас. Вне всякого сомнения, эта заметка подобна короткому сообщению или твиту и смысл её, как отмечено в комментариях "qml позволяет разрабатывать интерфейс очень быстро, qml рулит", поэтому возможно её стоит переименовать в "qml: могущество и простота. Часть 1-ая. Смысловая", а все технические подробности продолжить в статье "qml: могущество и простота. Часть 2-ая. Техническая". Но пока ограничимся этим комментарием.
Я полагал, что хабр это место где разработчики (и другие люди связанные с разработкой ) могут обмениваться опытом и мнениями. Пока я человек новый и пробую себя в различных жанрах. Этот часть моего обучения. Вы можете указать какого рода бы статьи Вам хотелось видеть — это будет ценно для меня. Критика мало конструктивная.
В любом случае, буду рад решению на php (люблю это язык), и читателям, думаю, оно будет полезно.
P.S. Спасибо, что посмотрели код. setContextProperty использовали вместо qmlRegisterType по той причине, что модель в нашем случае не является тиражируемой сущностью, а единичным объектом к которому нужно получить доступ из кода на qml. Так что mobyGamesModel это просто связующее звено между моделью на С++ и кодом на java script.