Для начала стоит оговориться о двух вещах: во-первых, идеала не существует, а само понятие “идеальный” сугубо индивидуально; во-вторых, самого понятия “шаблонизатор” как бы не существует – такого слова нет ни в концепции MVC, ни в общепринятых шаблонах проектирования. Просто русскому человеку из слов “вид” (View из MVC), “система обработки представления” и “шаблонизатор” последнее как-то ближе – с одной стороны, это достаточно короткое, но ёмкое имя, с другой, в отличие от “вид”, “шаблонизатор” подразумевает какое-то действие, совершаемое самим механизмом.
Переходя непосредственно к понятию шаблонизатора, отмечу, что здесь я буду говорить о веб-шаблонизаторах, то есть тех, которые отдают HTML на основе каких-то данных.
Буквально на днях мне пришлось столкнуться с шаблонизатором в одной платной CMS – Amiro. До этого я работал с некоторыми другими способами выдавать HTML на основе данных, и система шаблонизации в амиро мне представилась просто чудовищной.
Неудачная попытка увязать принципы XSLT с PHP не через теперь стандартную библиотеку, а собственным синтаксисом, явно провалилась – помимо отсутствия подсветки в любом редакторе и нагромождённого синтаксиса, основное, по моему мнению, преимущество – минимизация дублирования кода- быстро улетучивается. Также я так и не смог на 100% понять как там вообще работают перменные шаблонов – в коде одной переменной может встретиться несуществующая переменная, но её значение всё равно появится в выводе.
Ещё один немаловажный просчёт – огромная разбросанность HTML-кода по системе. Итоговая страница формируется из нескольких десятков шаблончиков, которые лежат в 5-7 папках, а некоторые – непосредственно прикреплены к контенту. Видимо, по этой причине в вывод также попадают служебные теги с названием шаблона, который отвечает за вывод последующего блока – без таких подсказок разобраться, что откуда появляется, становится крайне проблематично.
Заканчивая вводную часть, добавлю, что я не буду говорить о синтаксисе – по этой теме и так сломано немало копий, например, здесь: http://alexlebedev.com/blog/on-html-templates/
Качества идеального шаблонизатора
- Удобный синтаксис
- Грамотная декомпозиция шаблонов
- Удобное хранение шаблонов
- Удобная интеграция интернационализации
Разберём каждый пункт подробнее.
Удобный синтаксис
Удобство – вещь индивидуальная. В любом случае, синтаксис не должен быть обременяющим.
Говоря о необходимости подражанию синтаксиса шаблонизатора языковым конструкциям HTML или PHP, я, обращаясь к своему опыту, могу сказать твёрдое “нет”.
Когда синтаксис логических конструкций (условий, циклов) отличается от синтаксиса разметки (блоки, ссылки, списки), это помогает в один момент времени концентрироваться на одном, а также быстро переключаться (благодаря различию в синтаксисе) между логикой и разметкой.
При этом я ориентируюсь на опыт работы с Blitz (более-менее удобоваримая вещь), Smarty (пока лучшее, что видел, впрочем не без недостатков), синтаксисом логики вроде
<if:bla-bla><block /></if>
и Native PHP. Последние два в силу громоздкости быстро надоедают, начинают обременять лишними деталями (символами).
Грамотная декомпозиция шаблонов
Под декомпозицией шаблонов я понимаю разбиение итогового общего HTML-кода на отдельные смысловые блоки, которые также могут вкладываться друг в друга.
Декомпозиция шаблонов подразумевает некоторую вложенность шаблонов – как минимум, шаблон модуля вкладывается в общий шаблон. Идеальным уровнем вложенности я считаю числа порядка 2-3. Реализовывать вложенность следует аккуратно. Слишком глубокая вложенность излишне абстрагирует от общего документа, а излишне малая – порождает сильное дублирование кода.
Помимо декомпозиции исходного HTML-документа, не стоит забывать про декомпозицию CSS и JS слоёв. Впрочем, возможно, здесь это необходимо лишь при объёме проекта выше среднего, либо при командной разработке.
Удобное хранение шаблонов
Шаблоны – не ядро, могут меняться хоть каждый день. В таких условиях удобство редактирования кода шаблона выходит на первый план. Пожалуй, самый противный вариант – простейшая форма редактирования в браузере. Отсутствие вспомогательных инструментов компенсируется возможностью изменить внешний вид сайта с любого компьютера. Впрочем, большинству это не надо. Какой-либо редактор на JS картины не меняет. Идеальный шаблонизатор хранит шаблоны в файлах, которые можно легко редактировать по FTP, используя свой любимый редактор с подсветкой, code snippets и прочими радостями современного верстальщика.
Если говорить об организации файлов, то очень желательно, чтобы все шаблоны лежали в одном дереве, или одной папке (если шаблонов не больше пары десятков). Когда я начал реализовывать этот принцип, то думал “вау, я могу изменить абсолютно весь дизайн моего сайта просто поменяв папку”, а теперь я думаю “хм, где это у нас выводится? так, пойду в то дерево, где у меня все шаблоны”.
Удобная интеграция интернационализации
Сейчас достаточно сайтов, которые ориентируются на более чем 1 язык. И шаблоны не должны затруднять перевод сайта на другой язык. В идеале шаблон не будет жёстко привязан к языку – вся работа с фразами на разных языках должна быть возложена на отдельную подсистему.
Впрочем, вариант с разными шаблонами под разные языки тоже имеет право на существование. Их можно хранить в папке компонента, или создавать отдельные деревья шаблонов (начиная с корня) для каждого языка. Второе применимо к тем сайтам, дизайн которых сильно отличается для разных языков.
Выводы
Подводя итог, можно сказать, что хоть идеала и не существует, но чёткое понимание этих недостижимых полезных и важных качеств сильно увеличивает логичность и обоснованность выбора тех или иных техник и инструментов отображения данных. А каков идеальный шаблонизатор с вашей точки зрения?
| 
опубликовано: 10 февраля 2009, 23:39
Сегодня я хотел бы затронуть такую тему, как использование HTML-верстальщиком различных браузеров. А точнее, поделиться своим подходом к оному.
Во-первых, для начала следует определиться с распределением "рынка сбыта" - долями различных браузеров у пользователей. А поможет нам в этом
статистика от LiveInternet. Какая-никакая, а выборка. Несколько субъективное мнение, но я считаю, что верстать нужно по сути под первые 6 браузеров - IE 6, IE 7, Opera 9, Opera Mini, Firefox 2, Firefox 3. На самом деле, вся вёрстка разделится на 2-4 стиля - под настольные браузеры(возможно, отдельно под IE 6, IE 7) и Opera Mini. По сути, что под Opera Mini, что под другие PDA-браузеры, файл стилей может быть один. На стороне сервера мы просто смотрим User-Agent и отдаём мобильной опере нужный CSS-файл, а всем остальным - обычные, для IE можно использовать
conditional comments. Теперь подробнее об инструментарии.
Разработка. Firefox 2 + Firebug + Web Developer Toolbar. Это стандарт де-факто. Крайне функционально и удобно. Я в дополнение к этим плагинам использую IE Tab, зачастую удобнее чем окно Internet Explorer'а. И какой-нибудь текстовый редактор. Я привык к UltraEdit. И, конечно, фотошоп или аналог для резки PSD-макета.
Тестирование. Virtual Machine. Virtual Box с Windows XP на борту - широкое поле для экспериментов. Там у меня стоят: Firefox 3, Opera 9.23, Opera 9.27, Opera 9.5, Safari 3.1.2, Internet Explorer 8 Beta 1(включен в режим симуляции IE 7). Таким образом, я охватываю очень широкий спектр браузеров на PC. Остальные платформы куда менее распространены. Впрочем, есть ещё Mac. Можно, конечно, купить MacBook или что-то подобное для тестов или для пользования, но заядлым PC-шникам это может оказаться невыгодным. Сам я пока не дошёл до
виртуализации Mac OS X на PC, но это дело времени и трафика
Для тестирования в Opera Mini я использую
эмулятор от производителя, затем тестирую на своём телефоне. Требуется это далеко не всегда, но уж если делать на 100% грамотно - это необходимо.
Надеюсь, что кому-нибудь моя статья поможет. И если ещё кто-то думает, ставить виртуальную машину или нет - решит, что ставить. Ведь переустановить ось, откатиться, связать в "сеть" несколько машин куда проще используя технологии виртуализации. Как всегда, жду ваших комментариев.
[8] | опубликовано: 16 июля 2008, 23:27
В предыдущей заметке я уже писал, что решил перенести выполнение скриптов на виртуальную машину ака Linux сервер. Мотив тогда был немного прозаичнее, чем просто желание покрутить на линуксе код – у меня начались глюки с веб-сервером под виндой. Видимо, стояла не-thread-safe сборка php и скрипты при параллельной загрузке начали валиться, видеть память друг друга и т.д.
Однако, поюзав некоторое время систему “пишу на Windows, выполняю на Linux” я решил откатиться к менее радикальной – “пишу и тестирую на Windows, окончательно проверяю на Linux”.
Суть схемы “пишу и тестирую на Windows, окончательно проверяю на Linux”
Всю разработку я веду под Microsoft Visual Studio с расширениями VS.PHP и VisualSVN. Также, на Windows-хост-машине установлен Tortoise SVN. Для тестирования давно поднят Денвер(мне нравится его система работы с виртуальными серверами, а вернее простой скриптик, добавляющий в hosts инфу о них), в одном из виртуальных серверов которого сделана рабочая копия репозитория с Linux-сервера. Также, стандартный денверовский MySQL выключен, вместо него поставлен MySQL Server 5.0. Однако, он сейчас не используется – главным SQL-сервером стал тот же MySQL 5.0, только на Linux-виртуальной машине. Также, на Linux поднят svn-сервер, FTP-сервер и настроен httpd.
Организация работы.
Имея уже настроенные 2 сервера – тестировочный и почти продакшн, мы можем, во-первых, удобно тестировать проект под разными средами, а во-вторых(дело вкуса), писать под удобным(для кого как, но для меня удобным) Visual Studio, при этом быстро проверяя как себя ведёт код не только под Windows, но и под Linux.
Всю писанину я провожу под Windows. Написав какой-то код, я отлаживаю его на локальном тестировочном сервере. Затем, если всё в порядке – делаю Commit изменений и они вносятся в репозиторий на Linux-SVN-сервере. Затем, SVN, юзая hook post-commit делает chekout(проверку и обновление) рабочей копии в папке /var/www/html на Linux-сервере. То есть при commit’е я сразу вижу обновлённый код в папке Apache под Linux’ом. Далее я уже перехожу к тестированию кода под Linux.
Профилирование и отладка
Заниматься профилированием под Windows, я считаю, не очень выгодно и очень неудобно. А вот отлаживать на Windows вполне себе можно. Начиная с обычных var_dump’ов и заканчивая продвинутой отладкой с breakpoint’ами(правда до этого я ещё не успел дойти).
Гораздо интереснее дела обстоят под Linux. Там также есть xDebug, но ещё есть удобный инструмент профилирования – kCacheGrind. И если его аналог под Windows, WinCacheGrind, глючен и убог, то kCacheGrind очень юзабельный продукт. Естественно, бесплатный. То есть, я занимаюсь основной отладкой под Windows, а профилированием – под основной средой выполнения, то есть Linux.
При внесении правок под Linux, можно не волноваться за Windows-сторону: после изменения кода нужно сделать commit со стороны рабочей копии под Linux-Apache-сервером и на Windows-стороне сделать Update. Тогда обе копии будут идентичны.
Думаю, я разъяснил преимущества, с моей точки зрения, Windows-конструирования и Linux-выполнения. Кто-то предпочитает полностью сидеть в Linux, я же пока к этому не готов. Новички в PHP вообще редко задумываются о Linux-использовании, ведь чтобы поставить Linux, PHP, SVN, MySQL и т.д. это нужно много(мы говорим о новичках) времени и сил. Я же пока остановился на вышеизложенном варианте. Спасибо за внимание.
[1] | опубликовано: 6 июля 2008, 10:54
Да, вот такой вот немного странный вопрос - а на чём, собственно, отлаживать скрипты PHP? С одной стороны - Windows более привычна, особенно начинающим, под неё много софта, который можно применить в веб-разработке(например, Visual Studio), да и IE под Linux, мягко говоря, другой. С другой стороны - писать лучше на той платформе, на которой скрипты будут использоваться. Так что же выбрать?
Я решил совместить - писать скрипты под Windows, а сам сервер крутить на Linux. Как? Очень просто. Виртуальная машина. Всё-таки Windows у меня уже несколько лет, поэтому переходить на Linux в ближайшее время не собираюсь, следовательно, мой выбор очевиден - поставить VM на Windows и уже на VM - Linux.
Для начала я скачал виртуальную машину. Microsoft VirtualPC почему-то отказался запускать Linux на виртуалке, VMWare оказался неподъёмным для моего GPRS-канала, а вот
VirtualBox подошёл прекрасно - и весит немного, и линукс запустил без ошибок, и бегает шустро. Уже на него я поставил Fedora Core 6(более свежей версии, к сожалению, не нашлось). Стоит отметить, что сначала я приобрёл Mandriva Linux Powerpack 2008 64 bit, однако не учёл одну деталь - Windows XP у меня 32-битная. Поэтому от мандривы пришлось отказаться.
Затем, настроил сеть, поставил PHP, MySQL, некоторые расширения, которые использую в своём проекте, а также SVN и графический клиент под него. Помогла мне в этом эта
статья, хоть и написана она для 7 версии, на 6 порядок действий был аналогичен. Затем я восстановил рабочую копию своего проекта на VM и (внимание!) назначил права на файлы - в линуксе апач обязательно требует аттрибута x(eXecutable, исполняемый) для скриптов, пользователям Windows будет немного непривычно.
После этого настал черёд тестов. В среднем, время выполнения уменьшилось с
75(для форума)/
100(для сайта) миллисекунд до
29(форум)/
22(сайт) миллисекунд. И это с использованием памяти в
70 мегабайт вместо
20(Apache)
+96(MySQL)
+64(Memcached) =
180 мегабайт на винде. То есть памяти занимает меньше, а работает в
3 раза быстрее даже на виртуальной машине. Загрузка процессора
0%(если выйти из Gnome), загрузка памяти, как я уже сказал, 70 Мб.
Надеюсь, кому-нибудь эта статья окажется полезной - тем, кто хочет попробовать поднять сервер под линуксом(а это задача из непростых для новичка), либо же тех, кому не нравятся текстовые редакторы/среды разработки под линукс. Не очень очевидное совместительство оказалось крайне выгодным сотрудничеством - каждая часть делает то, что у неё лучше получается.
[2] | опубликовано: 30 июня 2008, 19:04
Эта статья предназначена только для маньяков. Для кого слюнтявые сюсюкания над первым поцелуем перса неинтересны, а вот десятая партнёрша главгероя дома отмечается с размахом – ведь 10 это юбилей! Для кого 200 симолеонов в семейном бюджете это не кризис, а стартовый капитал для рывка в бизнес! Для тех, кто признаёт в игре всего 2 скорости – паузу и наибыстрейшую! Здесь я поделюсь своими мыслями о том, как создать идеального на мой взгляд персонажа.
Чтобы создать идеального перса надо уяснить – одной жизни мало. К счастью, в симсах есть крутая вещь – элексир жизни. Он покупается за очки, которые дают за удовлетворение потребностей персонажа. Отсюда вывод – тщательно выбираем жизненные цели перса – романтику не интересно учить теоремы, поэтому будущие потребности следует согласовывать с текущими возможностями(или хотя бы планируемыми). Постоянно добиваясь поставленных целей, персонаж будет пребывать в эйфории, у него всё в жизни будет отлично, так что правильные цели – залог долгой и счастливой жизни.
Но идеальный перс не только счастлив – он ещё и богат. Чтобы разбогатеть нужно многое уметь. Чтобы многое уметь нужно много учиться. Чтобы много учиться нужно много свободного времени. Чтобы было много свободного времени нужно быстро и эффективно выполнять дела и садиться учиться. Таким образом, особо нет смысла пытаться разбогатеть, пока персонаж неграмотен и почти не имеет навыков.
Первым делом я даже у мужских персов прокачиваю кулинарию. Тогда они начинают готовить быстро, сытно, еда у них не пригорает и они не стоят в истерике каждую неделю после того, как у них загорится плита. Затем прокачиваю профессиональные навыки. Затем – все остальные.
Хорошо владеющий разными специальностями персонаж открывает следующую ступень совершенства – достичь вершины на нескольких работах. К слову, за достижение каждой вершины герою даётся какой-нибудь интересный бонус. Они зачастую куда полезнее и интереснее обыденных вещей вроде тренажёра или скрипки.
В свободное от работы время также можно зарабатывать деньги – на хобби. Например, рисовать картины, торговать конфетами или открыть офис на дому. Я предпочитаю первое – ненапряжно, поднимает досуг, да и за картину дают достаточно – получается 700-800 симолеонов за вечер.
Со временем денег может стать очень много. Вот тогда и можно задуматься о том, чтобы перехать на новый участок, поставить игру на паузу, отгрохать особняк по собственному вкусу, с бассейном, гаражом, вертолётной площадкой и космодромом на заднем дворе… Чтобы потом снова включить игру на полную скорость и заработать за неделю очередные пять десятков тысяч симоленов.
[1] | опубликовано: 27 мая 2008, 22:04
<< Предыдущая страница