Кстати, по поводу шрифтовых иконок — я бы не был столь категоричен, восхваляя их.
У этого подхода среди прочих есть один огромный, фундаментальный и непобедимый недостаток: в маленьких размерах они практически всегда выглядят ну очень ущербно в сравнении с растровыми, результат совершенно неприемлем, если нужны иконки, скажем, размера 16х16 или 12х12 пикселей (как это почти всегда и бывает).
Наверняка многие части вашей работы, не расходящиеся в идеалогии с оригинальным бутстрапом, можно законтрибьютить и туда. Вот это было бы действительно очень здорово!
А в чем отличие вашего детища от, к примеру, AspectPHP?
Вполне успешно выполняет ту же задачу тем же способом (судя по беглому ознакомлению с вашими исходниками), код очень качественный и с документацией, никаких расширений PHP естественно не требует, работает с PHP 5.3
Хм, да и блочное наследование есть же в jade докучи к факту, что jade таки работет на клиенте (я вполне успешно юзаю).
Причем интуитивно оно мне нравится больше и выглядит богаче чем то, что описано в доке к blade (просто параметризированные блоки).
Из раздела Why use Blade instead of Jade? в документации, если честно, не вдохновил ни один пункт.
Несмотря на это, я верю, что там больше позитивных сторон, чем я смог увидеть при беглом осмотре. Просто требуется какое-то более фундаментальное сравнение с jade, а не фразы в документации вида
Jade is an ornamental stone. Blade is a badass vampire hunter
Да, речь о статическом класcе Yii.
Потому что это типичный антипаттерн magic object / god object, просто отчаянно нуждающийся в декомпозиции.
Я считаю, с этим можно что-то сделать, не свалившись в пропасть java way.
Мне вот абсолютно не понятно, как при фантастический убогости Rage of Bahamut и великолепии Magic the Gathering, в топе может находиться именно первая из этих игр
Очень интересно, но:
Привязка данных к разметке к сожалению не имеет отношения к веб-компонентам, это исключительно имплементация на Dart'e, не веб-стандарт.
И жаль, для меня к примеру native data-binding был бы самой заманчивой фичей.
Об этом стоило сказать в статье, чтобы не вводить читателей в заблуждение касательно стандарта веб-компонентов.
У этого подхода среди прочих есть один огромный, фундаментальный и непобедимый недостаток: в маленьких размерах они практически всегда выглядят ну очень ущербно в сравнении с растровыми, результат совершенно неприемлем, если нужны иконки, скажем, размера 16х16 или 12х12 пикселей (как это почти всегда и бывает).
Вполне успешно выполняет ту же задачу тем же способом (судя по беглому ознакомлению с вашими исходниками), код очень качественный и с документацией, никаких расширений PHP естественно не требует, работает с PHP 5.3
В чем дело? LSB в PHP поддерживается с версии 5.3
Причем интуитивно оно мне нравится больше и выглядит богаче чем то, что описано в доке к blade (просто параметризированные блоки).
Из раздела Why use Blade instead of Jade? в документации, если честно, не вдохновил ни один пункт.
Несмотря на это, я верю, что там больше позитивных сторон, чем я смог увидеть при беглом осмотре. Просто требуется какое-то более фундаментальное сравнение с jade, а не фразы в документации вида
var res; fs.readFile(fileName, function(err, data){ res = data; });получаем
А если нужно что-то делать параллельно — используем вместо sync метод future и достаем результат через result getter
1. На сайте node-fibers жирным шрифтом выделено:
2. Смотрим в качестве примера такой абстракции node-sync. Здесь уже с сахаром.
(Пардон, что второй раз в посте эта ссылка)
Потому что это типичный антипаттерн magic object / god object, просто отчаянно нуждающийся в декомпозиции.
Я считаю, с этим можно что-то сделать, не свалившись в пропасть java way.
Привязка данных к разметке к сожалению не имеет отношения к веб-компонентам, это исключительно имплементация на Dart'e, не веб-стандарт.
И жаль, для меня к примеру native data-binding был бы самой заманчивой фичей.
Об этом стоило сказать в статье, чтобы не вводить читателей в заблуждение касательно стандарта веб-компонентов.