Для этого и разработана система модулей. В модуль включается процедура конфигурирования.
Сейчас правда проще через глобальный конфиг все фигачать, нестабильный механизм какой-то =(, но в архитектуре все предусмотрено уже!
Согласен, здоровый консерватизм и инертность в таких фундаментальных вещах, как система сборки, иногда не лишние.
Но и мучаться от ущербного дизайна тоже вечно нельзя. Надо переходить… и qbs предлагает отнюдь не эволюционный метод.
в случае с типом сборки — проигнорирует, если у вас не настроены специальные цели. application, «staticlibrary» — это не зашитые типы, они настраиваются в модулях.
cpp — скажет что нет такого свойства (модуля).
Свойства не обязательно строками — можно любые допустимые в JS. главное чтобы модуль это обработал.
я могу property variant foo: 'blah'; задать и обрабатывать его либо как строку либо как массив.
Можно объекты и тп. (в общем, смотрим доки по QML)
Хм, не думал о таком, спасибо за идею. Принимаю. А пока можете сравнить pro и qbs файлы в исходниках QtCreator, как я уже упоминал. На мой взгляд, ЧИТАЕМЕЕ на порядок.
Если хочется монструозный примерище, я дал ссылку — исходники Qt Creator. Там куча qbs модулей, со сложными скриптами. Работает. Я с их помощью и разбирался в хитросплетениях.
Пока QBS не выйдет на стадию альфы хотя бы, вам все равно придется изучать синтаксис «всех этих». Ну и тем более библиотеки вроде буста вряд ли на него перейдут даже в отдалённом будущем.
Пока главное преимущество — скорость. По сравнению с nmake — более чем в два раза. Какая принципиально разница будет если я вместо сборки 2х приложений вставлю 10?
А вот насчет более сложных либ, с наследованием и прочими вкусностями согласен. Просто не стал раздувать статью для первой публикации.
Штука действительно занимательная. Вот сейчас только закончил разбираться с написанием плагинов и ковырянием кода для поддержки сканирования по маске, надо будет рассказать потом)
qbs — система сборки, которая должна в теории заменить qmake (его поддерживать дальше никто не хочет). Просто переход на него в плане сборки qt5 еще ой как затянется (пока собирают им creator). Видно до тех пор пока не стабилизируется. Пока активно пилится ветка wip/qbs, никто особо ковырять его не хочет (кроме энтузиастов кроме меня-см ниже)
Я тоже заметил появляется через раз. Так же как alt+Return иногда срабатывает. В качестве совета могу подсказать снять выделение/курсор туда-сюда. С «Create implementation» по крайней мере так и работает. В этой штуке системы не увидел. Но для меня эта самая долгожданная, за день успел уже раз пять использовать!
Zend_Form все же с моделями не связан никак — с легкостью реализовывал описанные в статье «проблемы» валиадации без всякого напряга. Так что «not affected».
Интуитивно с Вами согласен, но так можно сказать что firefox занимает 7 мб, значит он не может не тормозить. Или тормознутость мерять размером (да вообще зачастую бывает даже обратное соотношение).
Так что 900 килобайт сильно оптимизированного (типизированные массивы etc.) кода на JS может быть быстрее чем while(true) { do_nothing(); }
я думаю это все же не на уровне polyfill, а скорее proof of concept…
выкокопроизводительные js-движки все же в тех браузерах что и так indexedDB поддерживают (polyfill это обычно чтото ие-костыле-подобное, а там этот js будет ой как тормозить)
И ИМХО, все же «то, что ваш инструмент может повести себя не так, как вы ожидаете — факт» — пахнет желтизной. Инструмент ведет В ТОЧНОСТИ как в документации. Я бы еще понял если бы это было недокументированными возможностями:
Замечание: К выражению, указанному вами как условие объединения, не применяется автоматическое заключение в кавычки. Если нужно заключить в кавычки имена столбцов, то используйте quoteIdentifier() при формировании строки условия объединения.
(то же касается других частей. Да и вообще, если бы про where автор не написал, я бы и не начал свой комментарий писать).
having — не экранирование указано в документации… в тех редких случаях что там используется используем quoteIdentifier
union — обычно там идет подзапрос, уже составленный через $select->assemble(), т.е. с экранированными данными. так что повторное экранирование излишне.
where — насчет NQ наглая ложь! читаем документацию:
$select->where(' id=?', $userEvilData); — первый параметр и не должен экранироваться.
в $where-массивах в TableAbstract та же фигня — с плейсхолдерами все прекрасно экранируется.
Что касается join-ов, есть недостаток, согласен — но в условии соединения таблиц пользовательский ввод сам по себе смотрится странно, так что я за время долгой практике не упирался в это ограничение.
Как по мне — так использовать можно, но как и другие инструменты — с умом. Использовал в двух проектах, предварительно почитал документацию про known issues — проблем не было. Анимированные и динамические блоки, проблем даже в ие6 не было. Но считаю что пихать его везде и всюду не стоит.
Создал у себя в LESS mixin:
и применял его для некоторых блоков, для которых критичны эти уголки, тенюшки и прочая. Все довольны )
В общем, либо проектов сложных не было, либо я везунчик, не знаю.
Сейчас правда проще через глобальный конфиг все фигачать, нестабильный механизм какой-то =(, но в архитектуре все предусмотрено уже!
Но и мучаться от ущербного дизайна тоже вечно нельзя. Надо переходить… и qbs предлагает отнюдь не эволюционный метод.
cpp — скажет что нет такого свойства (модуля).
Свойства не обязательно строками — можно любые допустимые в JS. главное чтобы модуль это обработал.
я могу property variant foo: 'blah'; задать и обрабатывать его либо как строку либо как массив.
Можно объекты и тп. (в общем, смотрим доки по QML)
А вот насчет более сложных либ, с наследованием и прочими вкусностями согласен. Просто не стал раздувать статью для первой публикации.
Уже вторую неделю его мучаю, написал несколько модулей, шустрая, гибкая, удобная штука.
white-space: pre-wrap;в стилях Хабра.
Так что 900 килобайт сильно оптимизированного (типизированные массивы etc.) кода на JS может быть быстрее чем while(true) { do_nothing(); }
выкокопроизводительные js-движки все же в тех браузерах что и так indexedDB поддерживают (polyfill это обычно чтото ие-костыле-подобное, а там этот js будет ой как тормозить)
Замечание: К выражению, указанному вами как условие объединения, не применяется автоматическое заключение в кавычки. Если нужно заключить в кавычки имена столбцов, то используйте quoteIdentifier() при формировании строки условия объединения.
(то же касается других частей. Да и вообще, если бы про where автор не написал, я бы и не начал свой комментарий писать).
union — обычно там идет подзапрос, уже составленный через $select->assemble(), т.е. с экранированными данными. так что повторное экранирование излишне.
where — насчет NQ наглая ложь! читаем документацию:
$select->where(' id=?', $userEvilData); — первый параметр и не должен экранироваться.
в $where-массивах в TableAbstract та же фигня — с плейсхолдерами все прекрасно экранируется.
Что касается join-ов, есть недостаток, согласен — но в условии соединения таблиц пользовательский ввод сам по себе смотрится странно, так что я за время долгой практике не упирался в это ограничение.
Создал у себя в LESS mixin:
и применял его для некоторых блоков, для которых критичны эти уголки, тенюшки и прочая. Все довольны )
В общем, либо проектов сложных не было, либо я везунчик, не знаю.