> Контроллер, точно не должен заниматься форматированием данных, как тут предлагали некоторые сторонники MVC :)
Полностью согласен.
> Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Как ты думаешь кто из нас двоих сделал большее количество больших проектов? :)
Не надо спорить о вкусе устриц с теми кто их ел.
> Понятно что скомпелированное приложение на Си будет работать куда быстрее ПХП.
Бугога) Слив засчитан.
Всё зависит от реализации обоих приложений. Можно на С написать приложение которое будет значительно медленее PHP-кода и бажнее.
Простой пример. На Си:
usleep(100000);
printf(«Hello world!\n»);
На PHP:
printf(«Hello world\n»);
Что выполнится быстрее?
> скомпелированное
… компИ…
Это вопрос к тем разработчикам. Но я бы тоже отказался т.к. не надо мешать язык и продукты написанные на нём. Хотя в PECL можно было бы и добавить (если б туда принимались расширения написанные на PHP).
Значит это не верстальщики. К примеру наши верстальщики положительно относятся к шаблонизаторам, которые дают инструментарий по модификации данных и логике.
> приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Чтобы выучить Quicky на уровне верстки нужен час. Это не так много если планируешь работать хотя бы месяц.
Не везде, а где это требуется. Если верстальщик берется за реализацию логики представления (написание шаблона) — его алгоритм должен генерировать XHTML без неочевидного поведения.
Почему по-вашему PHP + eAccelerator может быть быстрее PHP, но PHP + Quicky не может?
Расскажите разработчикам eAccelerator про задачу о Мюнхаузене, они ж не знают :-) Столько времени убили впустую оказывается.
Меня всегда улыбало слово «защита» в подобном контексте. Это не защита, а часть логики представления данных согласно правилам XHTML (XML). Это всё равно что экранирование спец. символов в строках участвующих в составлении SQL-называть защитой от SQL-инъекции и гонять через antihacker().
К информационной защите относится шифрование, защита от DDoS и т.д.
Если понадобится выводить данные не в HTML, а в plaintext например — менять бизнес-логику? Кстати, преобразовывать спец. символы XHTML в мнемонические последовательности нужно далеко не во всех переменных.
> и обработаны,
А это вообще отдает ламерством. Когда верстальщику надо будет обрезать новость до 150 символов, а не до 151 — буду насиловать мозг программисту. Хотя это воплощение логики ПРЕДСТАВЛЕНИЯ.
memory_cache.class.php — позволяет хранить кеш в shared memory.
stringtemplate.class.php — реализует механизм передачи текста шаблона из бизнес-логики.
В Quicky это реализуется несколько иначе (не через жопу). Посмотри _test/wrapper.php
Есть встроенные addon'ы в plugins/addons, а именно:
dbtemplate.class.php — болванка для выборки из бд.
Ужас. Не логику от представления надо отделять, а бизнес-логику от ЛОГИКИ представления. Вывод комментариев зеброй это тоже ЛОГИКА — логика представления. И шаблонизатор замечательно справляется с этой задачей, предоставляя удобный инструмент для описания логики представления.
В Smarty вообще очень очень много чего нет из того что есть в Quicky.
Например в Quicky если надо вывести дерево рекурсивно — достаточно сделать элементарный рекурсивный helper прямо в шаблоне.
1. Документирование запланировано, правда это не поможет, как метко сказал developer.
2. Стандарт кодирования у меня собственный. Нету несколько if'ов. Есть короткин if'ы в одну строку. Если не нравится — достаточно воспользоваться нормализатором кода.
3. Где?
> Идея хорошая, но таким образом вы ее убиваете на корню и развивать ее сами же будете. Единственным числом. Хотя вам не привыкать, как я вижу.
Меня это вполне устраивает.
Полностью согласен.
> Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Как ты думаешь кто из нас двоих сделал большее количество больших проектов? :)
Не надо спорить о вкусе устриц с теми кто их ел.
[+] Добавлен псевдо-компилятор PHP. См. _test/php-template.php
[~] Исправлены мелкие недочеты.
Бугога) Слив засчитан.
Всё зависит от реализации обоих приложений. Можно на С написать приложение которое будет значительно медленее PHP-кода и бажнее.
Простой пример. На Си:
usleep(100000);
printf(«Hello world!\n»);
На PHP:
printf(«Hello world\n»);
Что выполнится быстрее?
> скомпелированное
… компИ…
> приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Чтобы выучить Quicky на уровне верстки нужен час. Это не так много если планируешь работать хотя бы месяц.
Да да да) Хлеба и зрелищ! Сделайте аналог htmlspecialchars функцией MySQL ))) Вот смеху будет.
Расскажите разработчикам eAccelerator про задачу о Мюнхаузене, они ж не знают :-) Столько времени убили впустую оказывается.
К информационной защите относится шифрование, защита от DDoS и т.д.
Если понадобится выводить данные не в HTML, а в plaintext например — менять бизнес-логику? Кстати, преобразовывать спец. символы XHTML в мнемонические последовательности нужно далеко не во всех переменных.
> и обработаны,
А это вообще отдает ламерством. Когда верстальщику надо будет обрезать новость до 150 символов, а не до 151 — буду насиловать мозг программисту. Хотя это воплощение логики ПРЕДСТАВЛЕНИЯ.
?
Что-то ты намутил. Я прогнал тест по 0.9.6.4 — замечательно работает.
Ты скормил Quicky смартевые плагины?
stringtemplate.class.php — реализует механизм передачи текста шаблона из бизнес-логики.
Есть встроенные addon'ы в plugins/addons, а именно:
dbtemplate.class.php — болванка для выборки из бд.
Между прочим, добавлена возможность хранения кеша в shared memory =)
Например в Quicky если надо вывести дерево рекурсивно — достаточно сделать элементарный рекурсивный helper прямо в шаблоне.
2. Стандарт кодирования у меня собственный. Нету несколько if'ов. Есть короткин if'ы в одну строку. Если не нравится — достаточно воспользоваться нормализатором кода.
3. Где?
> Идея хорошая, но таким образом вы ее убиваете на корню и развивать ее сами же будете. Единственным числом. Хотя вам не привыкать, как я вижу.
Меня это вполне устраивает.