Околонаучные рассуждения о пользе и вреде шаблонных движков (вроде не флейм)

[Screjet]

svetasmirnova
Поправлю. Не только веб-интерфейс, но и полностью приложение привязано в этой БД.

Какой в этом случае смысл разделять данные и представление?

Приходит заказчик и говорит: хочу заказать новый дизайн в свете нового понимания юзабилити.
На что вы ему ответите: нужно разрабатывать все с нуля, т.к. новый дизайн слабосовместим с текущим. Или потребуете кучу денег (за кучу времени _програмеров_) соотвественно.
А реально там нужно только сменить хтмл. Работа верстальщика.

И не усложнит ли такое разделение дальнейшую поддержку?

Вобщем это такие грабли, что пока не наступишь, не узнаешь каково это.

 

[svetasmirnova]

>хочу заказать новый дизайн в свете нового понимания юзабилити.
...
>А реально там нужно только сменить хтмл. Работа верстальщика.

Но в нашем случае юзабилити привязано к СУБД, так что меняя юзабилити, мы в любом случае будем вынуждены менять логику: одной лишь вёрсткой тут не обойдёшься.

И ещё момент. У такого приложения не может быть сложных задач по обработке данных: одна база, одно направление разработки. То есть код перемешанный с HTML будет очень простым. Плюс отказ от MVC нам не мешает использовать модульный подход (как впрочем и любой другой).

 

[Demiurg]

Screjet
в этом случае придется менять view и controler, модель(структура базы) останется та же.

svetasmirnova
имхо, mvc - это всего лишь наиболее близкая архитектура для веб-приложений, вполне возможно. Мало того, мы сейчас говорим об абстрактных проектах, на практике же mvc используется в той или иной модификации, а еще более реально, когда проект живет своей жизнью и его технический дизайн слабо сочитается с теорией. Ну и конечно, вполне возможно когда за основу этого самого дизайна может быть взято что-то совсем отличное от mvc.

 

[Screjet]

Но в нашем случае юзабилити привязано к СУБД, так что меняя юзабилити, мы в любом случае будем вынуждены менять логику: одной лишь вёрсткой тут не обойдёшься.

Да, но времени на доработку будет потрачено минимум. Учти, что програмер такого "одноразового" кода тратит только 1/3 - 1/2 всего времени на то, чтобы разобраться, где втиснуть нужную логику. Причем затраты времени, на то, чтобы втиснуть другой хтмл такой же.

То есть код перемешанный с HTML будет очень простым.

Совершенно верно. Но поддержки не будет. Вообще. Проще потерять клиента и брать чтото новенькое "разрабатывать". Соответствующая низкая стоимость.

Это как автомобиль: берем классный, но дешевый: быстро ломается, ремонт дорогой. Берем классный и дорогой: не ломается +гарантия на 10 лет бесплатного ремонта.

 

[svetasmirnova]

Demiurg
>mvc - это всего лишь наиболее близкая архитектура для веб-приложений, вполне возможно

Да, этот концепт настолько завораживающе звучит и его слишком сложно оспорить, что, кажется, зарождается новый абсолют. А вот абсолюты я не люблю.

Screjet
>Это как автомобиль: берем классный, но дешевый:
Аналогия не уместна. Не вижу почему MVC дороже в разработке.

>Совершенно верно. Но поддержки не будет. Вообще.
Не факт. Как выше заметил Demiurg, менять придётся view и controler, причём архитектура может быть реализована с некоторым их разделением:

<?php
$params = create_params($_POST);
$data = xxx_query($params);
...
?>
beauty html
<?=$data['xxx']?>
beauty html
<?=$other_data->getSmth()?>
...

То есть можно даже наблюдать некоторое разделение на дизайн и данные. Преимущества? Отказ от контроллера: мы не выносим в программу сложные взаимосвязи и не заботимся о наличии модулей. Простота создания как у статического сайта. И в чём-то расширения: не нужно понимать архитектуры приложения для добавления новой возможности.

 

[Demiurg]

>зарождается новый абсолют.
Если абсолютом ты называешь реакцию на некое действие, которая записывается на уровне мозжечка, то да. Но если проектировщики не хотят, не могут думать или им не хватает на это времени, то тут ничего поделать нельзя.

 

[Screjet]

Не вижу почему MVC дороже в разработке.

Потому что его отсутвие проще/дешевле

менять придётся view и controler

Таки зачатки разделения есть?
А я говорил о

echo "<table style='...'>";
for(..){
  echo "<tr>";
  for(..){
    echo "<td style='..'>..</td>";
  }
  echo "</tr>";
}
echo "</table>";

svetasmirnova
Все одно Вы к этому придете, как бы не сопротивлялись.

 

[svetasmirnova]

Screjet
Я же не о том, что использую в настоящий момент Но о том: а нужно ли оно всегда и в таком виде и существуют ли web-приложения, в которых лучше обойтись без. А echo "<tr>"; и т.п. - это даже не тот пример мешанины из мануала, который Попов привел, создавая эту тему. Скорее мне напоминает пережиток из до-PHP-шного прошлого: Perl и т.п. А в PHP синтаксис изначально красивей.

 

[Дмитрий Попов]

svetasmirnova

Все выступавшие уверены, что MVC просто необходимо использовать

Не все. Господа, мне кажется, мы ушли от темы. Может модератор выделит последние постинги в отличную тему. Ибо, тема, лично меня касается мало, поскольку я считаю MVC абсолютно ненужным подходом, и аргументировать это не хочу.
А тема моя =)

 

[asm]

Автор оригинала: Screjet
Попробуй, спроектируй мультиязычное приложение. Не затачивая под шаблоны.

Читай внимательнее не затачивая под Smarty и т.п.

 

[svetasmirnova]

Дмитрий Попов
Похоже, я Вас постоянно не так понимаю:

Разделение кода и оформления – ну, это уже просто побочное и приятное последствие основной задачи.
MVC.
....
По этому, было бы интересно такого(вменяемого) все-таки найти. Или, возможно, какой-то аспект я еще не совсем учел.

ОК, вернёмся к теме шаблонов. А почему мы все рассматриваем вариант, описанный Screjet или, в лучшем случае, мной и совершенно забываем про подход, использующийся в PEAR_QuickForm ? Даже если отбросить все использующиеся там возможности (я несколько не в теме) и писать с нуля, для удобного программного создания тэга достаточно написать один класс с тремя атрибутами (название тэга, массив атрибутов и тело) и четырьмя методами (присвоить имя, добавить атрибут, присвоить тело, распечатать). Что мы выигрываем? Опять-таки обращусь к своему несуществующему клону phpMyAdmin, где логика неотрывно связана с представлением. Но в таком случае получается, что изменить дизайн не просто, а очень просто: мы меняем CSS и всё! Да, в жизни придётся немножечко доработать такой проект: добавить дефолтных обработчиков наших тэгов, которые подставляли бы дополнительные стили и группировали бы программно созданные элементы страницы, но, похоже, в этом случае, такой подход может быть эффективней шаблонов и совершенно без потери разделения роли дизайнера и программиста.

 

[kvf77]

Автор оригинала: chebhero
как Вы все задолбали своими CMS и смарти! да у вас у подавляющего большинства все жутко тормозит небось! У меня есть классные наработки очень быстрые для больших проектов, там ещё не всё готово но уже большую часть архетиктуры я придумал и дело за малым! это будет супер-хит. есть есть интерес - присодиняйтесь к моей комманде на http://chebhero.narod.ru/

У меня такое ощущение, что ты тут саморекламой занимаешься. Во всех твоих сообщениях ноль информации и смысла - хватит может засорять форум своим суперством? Достал уже.

-~{}~ 01.04.05 12:57:

Света, ну подходы бывают разными. Вы все время ссылаете сь на phpMyAdmin, однако ж такой подход наврядли станет эффективно работать в сложном приложении с разным количеством модулей и с разными типами данных. Как быть в этом случае? Помоему логичнее не выяснять какой способ вывода информации круче, а втоит выделить проблемы для которых подходит один способ и проблемы, для которых нужен другой подход.

 

[svetasmirnova]

kvf77
>выделить проблемы для которых подходит один способ и проблемы, для которых нужен другой подход.

Я и пытаюсь обрисовать более-менее серьёзную задачу при которой использование шаблонов не является лучшим выбором. И, стыдно признаться, как сделан phpMyAdmin - я не знаю: толком не смотрела, так как работает - и ладно. Но снова мне показалось, что все ранее выступавшие лихо используют исключительно шаблоны. А может не надо всегда и везде?

 

[kvf77]

Лично я сторонник разных подходов. Я не всегда и даже сказал бы, что часто использую не шаблоны. Но когда я делаю проект для сторонней организации и одно из условий, это чтобы он небыл привязан ко мне - я выбираю шаблоны, потому что мне это позволяет передать проект в готовом виде с минимальным обучением контент-менеджеров.

 

[asm]

IMHO:
А у меня сложилось впечатление что шаблоны не выгодно использовать в OpenSource проектах.
А за кастомизацию там можно и деньгу взять. Типа смотрите какой хороший продукт. Используйте
бесплатно, а хотите что бы он отмичался от 1000 других денюжка. Ну не видел я ни одного OpenSource
с шаблонами. Хотя давно не смотрел поделки может и появились с шаблонами.

Совсем недавно узнал, что PHPBB использует класс шаблонов... Некоторые даже используют данный класс.

 

[kvf77]

to asm:
гм - не вижу пречин, почему нельзя в Open проектах использовать шаблоны? Продавать можно суппорт, поддержку, настройку, продавать можно новый дизан и так далее. Я вижу причину отсутствия у многих Open проекто шаблонов потому что они зародились еще до того как начали появляться стоящие шаблонизаторы - вот и все - а готовый проект видимо сложно перевести на шаблоны ввиду серьезных реорганизаций в коде.

 

[asm]

Автор оригинала: kvf77
Я вижу причину отсутствия у многих Open проекто шаблонов потому что они зародились еще до того как начали появляться стоящие шаблонизаторы ...

тоесть до зарождения PHP?

 

[svetasmirnova]

тоесть до зарождения PHP?

Насколько я понимаю, и тогда шаблонизаторы были: Mason etc.
И я бы не стала разделять: использовать шаблонизаторы в OpenSource или нет. Для подобного выбора другими критериями стоит руководствоваться. Кстати, качественный OpenSource проет, где используются шаблонизаторы (Smarty) - это phpDocumentor

 

[Alien]

moderatorial:
1. Флейм из данной ветки будет стираться.
2. chebhero просьба сюда больше не писать.

 

[Rin]

По поводу шаблонизаторов есть очень интересная статья и примеры скриптов.

http://www.massassi.com/php/articles/template_engines/