-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Околонаучные рассуждения о пользе и вреде шаблонных движков (вроде не флейм)
- Автор темы Дмитрий Попов
- Дата начала
fisher
накатила суть
ребят, извините, я тут читал, читал, и окончательно перестал понимать.
можно немного лирики?
короче. реализация логики представления в любом проекте почти всегда будет наиболее простой задачей с интеллектуальной точки зрения. скажу честно, лично я вообще не вижу тут предмета для разговора "как нам туда-сюда"... а что, много вариантов? как только человек действительно понимает, КАК и ПОЧЕМУ надо разделять ЛОГИКУ ПРЕДСТАВЛЕНИЯ (не дизайн!) от прочего кода - потребность что-то обсуждать имхо пропадает почти полностью - остается договориться о деталях метода. и есть стратегическая линия, кто за что отвечает, и в какой последовательности делает. ее можно назвать MVC - как угодно - но не стОит за ней видеть стометрового монстра хитросплетенных классов, всё очень просто. мне всегда помогала следующая аналогия.
- кто пришел? что принес? что надо?
- ага, ну-ка, примите это у него. а вы несите его барахло к нам в закрома
- так, что у нас тут теперь... ясненько - ну, разберитесь, где там у нас что лежит для этого гражданина
- тэк-с, готово. щас, соберем, упакуем.. алё, где паковщик? ...
- вот-с, получите
всё (ну, понятно, с варициями). если на этапе "примите и унесите к нам" - тот, кто понес, вдруг примет, например, решение, КАК надо УПАКОВЫВАТЬ - то в огранизации, если она более-менее большая - будет бардак: там, выше - разберутся. а мое дело принести и сказать получилось, или не смогла. если писать программы по такому сценарию - ошибок будет меньше на порядок. остальное - уже почти не суть. если паковщик вдруг говорит "да вы с ума сошли, этот же просил ещё жидкость для распаривания ног "весна" " - и бежит за жидкостью для распаривания ног - это тоже бардак. и уже не важно, умеет ли паковщих foreach или не умеет. если он умеет foreach или if - это его достоиство, но только до тех пор, пока он его использует только при паковке.
поэтому, читая это
>>Я использую шаблонизатор – самый, что ни на есть
>>простой – xtemplate (xtpl.sourceforge.net). Но могла ли моя система
>>существовать без него? Не могла бы
невольно кажется, что где-то таки ошибка при проектировании есть
P.S. а какому товарищу первому пришла в голову мысль перевести template engine как шаблонизатор? в английском языке есть "шаблонизатор"? догадываюсь, кстати
можно немного лирики?
короче. реализация логики представления в любом проекте почти всегда будет наиболее простой задачей с интеллектуальной точки зрения. скажу честно, лично я вообще не вижу тут предмета для разговора "как нам туда-сюда"... а что, много вариантов? как только человек действительно понимает, КАК и ПОЧЕМУ надо разделять ЛОГИКУ ПРЕДСТАВЛЕНИЯ (не дизайн!) от прочего кода - потребность что-то обсуждать имхо пропадает почти полностью - остается договориться о деталях метода. и есть стратегическая линия, кто за что отвечает, и в какой последовательности делает. ее можно назвать MVC - как угодно - но не стОит за ней видеть стометрового монстра хитросплетенных классов, всё очень просто. мне всегда помогала следующая аналогия.
- кто пришел? что принес? что надо?
- ага, ну-ка, примите это у него. а вы несите его барахло к нам в закрома
- так, что у нас тут теперь... ясненько - ну, разберитесь, где там у нас что лежит для этого гражданина
- тэк-с, готово. щас, соберем, упакуем.. алё, где паковщик? ...
- вот-с, получите
всё (ну, понятно, с варициями). если на этапе "примите и унесите к нам" - тот, кто понес, вдруг примет, например, решение, КАК надо УПАКОВЫВАТЬ - то в огранизации, если она более-менее большая - будет бардак: там, выше - разберутся. а мое дело принести и сказать получилось, или не смогла. если писать программы по такому сценарию - ошибок будет меньше на порядок. остальное - уже почти не суть. если паковщик вдруг говорит "да вы с ума сошли, этот же просил ещё жидкость для распаривания ног "весна" " - и бежит за жидкостью для распаривания ног - это тоже бардак. и уже не важно, умеет ли паковщих foreach или не умеет. если он умеет foreach или if - это его достоиство, но только до тех пор, пока он его использует только при паковке.
поэтому, читая это
>>Я использую шаблонизатор – самый, что ни на есть
>>простой – xtemplate (xtpl.sourceforge.net). Но могла ли моя система
>>существовать без него? Не могла бы
невольно кажется, что где-то таки ошибка при проектировании есть
P.S. а какому товарищу первому пришла в голову мысль перевести template engine как шаблонизатор? в английском языке есть "шаблонизатор"? догадываюсь, кстати
Дмитрий Попов
сторож
fisher
Ну, во первых эта фраза касалась исключительно автогенерации back-end'а, что в принципе несколько другое, и где, как я счиатю, в принципе логика вывода определяется логикой данных.
Что же касается frontend'а - то здесь ограничений никаких не лежит, и можно использовать абсолютно любой подход.
-~{}~ 02.04.05 12:29:
fisher
И, кстати, логика представления (не дизайн) как раз таки отделена от основновного кода. Только не шаблонизатором а самим кодом. Подробнее объяснить не смогу пока что.
Ну, во первых эта фраза касалась исключительно автогенерации back-end'а, что в принципе несколько другое, и где, как я счиатю, в принципе логика вывода определяется логикой данных.
Что же касается frontend'а - то здесь ограничений никаких не лежит, и можно использовать абсолютно любой подход.
-~{}~ 02.04.05 12:29:
fisher
И, кстати, логика представления (не дизайн) как раз таки отделена от основновного кода. Только не шаблонизатором а самим кодом. Подробнее объяснить не смогу пока что.
Дмитрий Попов
сторож
Я знаю. Потому что её некоторые несознательные личности увели куда в сторону, и я сам уже не понимаю куда =)
svetasmirnova
маленький монстрик
Хороши же рассуждения, которые можно так увести ;-)
Дмитрий Попов
сторож
Screjet
Да, неподвластно.
Причина довольно проста - я живу в реальном мире, в котором интеграция шаблонов, лежит, увы на разработчике, а верстальщик (который, как правило - дизайнер) боится даже попытаться заняться логикой, в результате и в дальнейшем во время сдачи сайта изменениями шаблонов приходится заниматься разработчику (т.е. мне).
Потому, я сделал систему, которая удобна мне. И она действительно сверх удобна для меня.
А шаблоны настолько просты, что верстальщик их уже не боится, и сам начинает править. Что опять же удобно мне.
Да, неподвластно.
Причина довольно проста - я живу в реальном мире, в котором интеграция шаблонов, лежит, увы на разработчике, а верстальщик (который, как правило - дизайнер) боится даже попытаться заняться логикой, в результате и в дальнейшем во время сдачи сайта изменениями шаблонов приходится заниматься разработчику (т.е. мне).
Потому, я сделал систему, которая удобна мне. И она действительно сверх удобна для меня.
А шаблоны настолько просты, что верстальщик их уже не боится, и сам начинает править. Что опять же удобно мне.
Screjet
Новичок
Дмитрий Попов
Интересная позиция.. Даже очень.
Одно время мучал вопрос: кто старший в разработке сайта: програмер, либо верстальщик.
Первое вермя решил, что програмер (т.к. мне это удобно), но начались проблемы: шаблоны "дубовые" и по любому изменению нужно програмеру принимать участие. Вот тут и решил пересмотреть вопрос с позиции фреймворка.
Отображение (все. Включая дизайн и логику отображения) стихия верстальщика. А сайты, сами по себе, основаны полностью на отображении, и все что внутри (модель, конроллер) совершенно невидимы внешнему наблюдателю, т.е. инкапсулированы. Вот тогда и решил, что старшим должен быть верстальщик, а програмер уже работает на него, для его удобства.
Вот такая моя позиция.
Интересная позиция.. Даже очень.
Одно время мучал вопрос: кто старший в разработке сайта: програмер, либо верстальщик.
Первое вермя решил, что програмер (т.к. мне это удобно), но начались проблемы: шаблоны "дубовые" и по любому изменению нужно програмеру принимать участие. Вот тут и решил пересмотреть вопрос с позиции фреймворка.
Отображение (все. Включая дизайн и логику отображения) стихия верстальщика. А сайты, сами по себе, основаны полностью на отображении, и все что внутри (модель, конроллер) совершенно невидимы внешнему наблюдателю, т.е. инкапсулированы. Вот тогда и решил, что старшим должен быть верстальщик, а програмер уже работает на него, для его удобства.
Вот такая моя позиция.
Demiurg
Guest
>кто старший в разработке сайта: програмер, либо верстальщик.
есть такое красивое слово - проджект менеджер.
есть такое красивое слово - проджект менеджер.
Дмитрий Попов
сторож
Demiurg
Ага. И кстати, проджект менеджеры, в отличие от "читых" верстальщиков, как правило все-таки существуют.
Screjet
1)
Я то же много думал.
И много видел.
К сожалению, глаза показывают мне, что есть - а мысли, всего-лиш что должно быть.
И вот, своими глазами я вижу, что в 95% случаев версткой занимается либо дизайнер, либо я. И что в 95% этих 95% случаев - дизайнер в принципе не будет париться с логикой. Не его это.
2) Только не надо мне только рассказывать про гипотетические случаи. Мы с Вами здесь не теорией занимаемся, а практикой.
А на практике, я вижу, что мне важно, что бы я сам мог, как можно проще работать с логикой. И шаблоны должны быть как можно проще. Что бы дизайнер мог вносить хоть мелкие правки.
К сожалению, моя многолетняя практика, так и не дала поводов, усомнится, в отсутсвии необходмости даже задумываться о профессиональном выделенном верстальщике.
Изменится практика, возможно я изменю идеологию. Пока моей идеологии хватает, с большим запасом.
Ага. И кстати, проджект менеджеры, в отличие от "читых" верстальщиков, как правило все-таки существуют.
Screjet
1)
Я то же много думал.
И много видел.
К сожалению, глаза показывают мне, что есть - а мысли, всего-лиш что должно быть.
И вот, своими глазами я вижу, что в 95% случаев версткой занимается либо дизайнер, либо я. И что в 95% этих 95% случаев - дизайнер в принципе не будет париться с логикой. Не его это.
2) Только не надо мне только рассказывать про гипотетические случаи. Мы с Вами здесь не теорией занимаемся, а практикой.
А на практике, я вижу, что мне важно, что бы я сам мог, как можно проще работать с логикой. И шаблоны должны быть как можно проще. Что бы дизайнер мог вносить хоть мелкие правки.
К сожалению, моя многолетняя практика, так и не дала поводов, усомнится, в отсутсвии необходмости даже задумываться о профессиональном выделенном верстальщике.
Изменится практика, возможно я изменю идеологию. Пока моей идеологии хватает, с большим запасом.
neko
tеam neko
Crazy
это ты о чем?
я знаю только одно MVCC
которое MultiVersion Concurrency Control
as in:
http://www.zope.org/Wikis/ZODB/MultiVersionConcurrencyControl
http://www.postgresql.org/docs/current/static/mvcc.html
собственно мой пост, просто дуратская шутка
ты что-то другое имел в виду?
это ты о чем?
я знаю только одно MVCC
которое MultiVersion Concurrency Control
as in:
http://www.zope.org/Wikis/ZODB/MultiVersionConcurrencyControl
http://www.postgresql.org/docs/current/static/mvcc.html
собственно мой пост, просто дуратская шутка
ты что-то другое имел в виду?
svetasmirnova
маленький монстрик
Crazy
А что есть MMVC?
А что есть MMVC?
Demiurg
Guest
>дело в том, что это парадигма, в свое время навязанная компанией microsoft целевой аудитории EULA
разве первое апреля не кончилось ?
разве первое апреля не кончилось ?
Demiurg
Guest
>это как раз шуткой не было
тогда объясни связь.
тогда объясни связь.