{declare name='depart_scopes'} сделано больше не для практического использования, а чтобы позволить постепенно переводить шаблоны на import/export/global/local… в конце перехода следует включить $tpl->depart_scopes = TRUE, и больше не писать {declare name='depart_scopes'}
Такая система позволяет лучше контролировать работу при коллективной разработке, значительно упрощает отладку, и понижает риск возникновения неполадок.
> Контроллер, точно не должен заниматься форматированием данных, как тут предлагали некоторые сторонники MVC :)
Полностью согласен.
> Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Как ты думаешь кто из нас двоих сделал большее количество больших проектов? :)
Не надо спорить о вкусе устриц с теми кто их ел.
> Понятно что скомпелированное приложение на Си будет работать куда быстрее ПХП.
Бугога) Слив засчитан.
Всё зависит от реализации обоих приложений. Можно на С написать приложение которое будет значительно медленее PHP-кода и бажнее.
Простой пример. На Си:
usleep(100000);
printf(«Hello world!\n»);
На PHP:
printf(«Hello world\n»);
Что выполнится быстрее?
> скомпелированное
… компИ…
Это вопрос к тем разработчикам. Но я бы тоже отказался т.к. не надо мешать язык и продукты написанные на нём. Хотя в PECL можно было бы и добавить (если б туда принимались расширения написанные на PHP).
Значит это не верстальщики. К примеру наши верстальщики положительно относятся к шаблонизаторам, которые дают инструментарий по модификации данных и логике.
> приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Чтобы выучить Quicky на уровне верстки нужен час. Это не так много если планируешь работать хотя бы месяц.
Не везде, а где это требуется. Если верстальщик берется за реализацию логики представления (написание шаблона) — его алгоритм должен генерировать XHTML без неочевидного поведения.
Почему по-вашему PHP + eAccelerator может быть быстрее PHP, но PHP + Quicky не может?
Расскажите разработчикам eAccelerator про задачу о Мюнхаузене, они ж не знают :-) Столько времени убили впустую оказывается.
Такая система позволяет лучше контролировать работу при коллективной разработке, значительно упрощает отладку, и понижает риск возникновения неполадок.
Полностью согласен.
> Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Как ты думаешь кто из нас двоих сделал большее количество больших проектов? :)
Не надо спорить о вкусе устриц с теми кто их ел.
[+] Добавлен псевдо-компилятор PHP. См. _test/php-template.php
[~] Исправлены мелкие недочеты.
Бугога) Слив засчитан.
Всё зависит от реализации обоих приложений. Можно на С написать приложение которое будет значительно медленее PHP-кода и бажнее.
Простой пример. На Си:
usleep(100000);
printf(«Hello world!\n»);
На PHP:
printf(«Hello world\n»);
Что выполнится быстрее?
> скомпелированное
… компИ…
> приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Чтобы выучить Quicky на уровне верстки нужен час. Это не так много если планируешь работать хотя бы месяц.
Да да да) Хлеба и зрелищ! Сделайте аналог htmlspecialchars функцией MySQL ))) Вот смеху будет.
Расскажите разработчикам eAccelerator про задачу о Мюнхаузене, они ж не знают :-) Столько времени убили впустую оказывается.