Форум PHP

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

Поделитесь, пожалуйста, опытом. Спасибо.

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

if($_SESSION['user'] == 0){ echo json_encode(['error'=>true, 'authed'=>false, 'description'=>'пользователь не авторизован']); } else{ echo json_encode(['error'=>false, 'authed'=>true, 'description'=>'bla-bla-bla', 'content'=>$content]); }

или типа того. ну и на фронт-энде делать проверку, если authed == false, то выводить окно авторизации, иначе - отображать то, что нужно.

хм, возникает несоклько вопросов
а) что если выдаваемый формат данных не json? Как сообщить, что сессия тю-тю?
б) если бэкэнд это javascript, им же и смотрим сессию получается? А если "родная" проверка это не просто переменная в куки, а сложнее, в т.ч. с несколькими запросами в БД, тогда как?

1. данные от формата не зависят. хоть xml, хоть что. суть не меняется - если парсинг нужного поля выдает true, то одно, если false, то другое.
2. бэк-энд - это серверный скрипт, не клиентский. если сложная проверка, то проверяйте то, что нужно. в чем проблема-то?

>1. данные от формата не зависят. хоть xml, хоть что. суть не меняется - если парсинг нужного поля выдает true, то одно, если false, то другое.
>2. бэк-энд - это серверный скрипт, не клиентский. если сложная проверка, то проверяйте то, что нужно. в чем проблема-то?

1. Если я правильно понял, то в рабочем режиме выдаём что есть, а если сессия — тю, то json с полями о том, что надо идти на авторизацию. Поля проверяем при любом раскладе. т.е. если они пришли, значит идём на авторизацию.

2. Да, пардон, конечно же серверный. Имелся ввиду фронтенд. Ну допустим так. Тогда если в коде ajax запросов (т.е. не самих запросов как таковых, а функций) N штук, то и проверку возвращаемого значения надо в каждом вызывать? Получается неуклюжая конструкция, сложная в обслуживании.

1. да.
2. ну, зависит от структуры системы. например, если используется какой-нить фреймворк, то можно в конструкторе контроллера проверку делать, а остальные контроллеры унаследовать от этого базового.

2. Ну, ситуация ясна. В моём случае, если ничего не менять, раз 30 придётся воткнуть проверку, и, втыкать её каждый раз, когда появится новая функция с ajax запросом. Накладно.

Если не затруднит, можете пояснить, что значит "конструктор контроллера" и дать примеры на фреймворки? Почитаю, может поможет чем нибудь.

Сейчас у меня используется jquery. И в сущности все функции запросов отличаются действиями по факту завершения успешного запроса и наличием некоторой разницы в действиях до выполнения запроса. Знаний не хватает, но может можно сделать как-то так, что бы функция ajax запроса была одна, а при её вызове можно было бы в качестве параметров указать, скажем, пару функций вызываемых до и после запроса. Вот тогда всё бы сильно упростилось. Но, увы, javascript я знаю паршивенько.

Надо начать с азов ООП. тогда все вопросы отпадут. ООП в пхп. Потому как конструктор контроллера - это конструктор класса. Контроллер - это класс в системе MVC. в общем, гуглите, читайте. начните с ООП. остальное приложится.

Если Ajax, то что мешает не позволить сессии "умереть"?

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

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

>Если ткнуть обычную ссылку, выполняется стандартная проверка на авторизацию

Как это понимать - авторизация один раз, если успешна, зачем проверка (или имеется ввиду проверка некоего токена?), а если нет, то и ссылок нет. А если асинхронный, то пофигу авторизован или нет?

Просили поделиться, поделюсь, а уж делать вам так или нет, решайте сами.

Административный раздел, вообще может весь работать на Ajax, гонять страницы полностью не нужно, более того, они совсем не нужны, нужны только данные определяющие какие либо значения (переменные). Шаблоны страниц административного раздела хранятся на клиенте. То есть это работает как и шаблонизатор - получили данные, загрузили шаблон, получили страницу. Естественно, что кроме шаблонов страниц на клиенте содержаться и клиентские сценарии, и файлы стилей.

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

Сессия умерла? Авторизуемся, все асинхронно, а не половина "в горошек", половина "в полосочку".

Если вас это страшит, переведите html-вариант свой весь на асинхронный обмен и не партесь.

>>Если ткнуть обычную ссылку, выполняется стандартная проверка на авторизацию
>
>Как это понимать - авторизация один раз, если успешна, зачем проверка (или имеется ввиду проверка некоего токена?), а если нет, то и ссылок нет. А если асинхронный, то пофигу авторизован или нет?

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

>Просили поделиться, поделюсь, а уж делать вам так или нет, решайте сами.

За что отдельное спасибо.

>Административный раздел, вообще может весь работать на Ajax, гонять страницы полностью не нужно, более того, они совсем не нужны, нужны только данные определяющие какие либо значения (переменные). Шаблоны страниц административного раздела хранятся на клиенте. То есть это работает как и шаблонизатор - получили данные, загрузили шаблон, получили страницу. Естественно, что кроме шаблонов страниц на клиенте содержаться и клиентские сценарии, и файлы стилей.

Интересный подход, давно на него смотрю, но пока не понимаю как он устроен. Сейчас точно переделывать не буду, но всё же интересно, как это шаблоны могу хранится на стороне клиента? Может предполагается, что они ему выгрузились один раз и далее просто используются?

>Специфика текущей задачи в том, что возвращать надо данные, которые касаются авторизованного юзера.

Опять не понятно. Административный раздел, это святая святых, и вход в него без авторизации означает взломано.
А у вас что получается - открыт кем-то кому не лень, а возвращаем данные только авторизованным?

>Может предполагается, что они ему выгрузились один раз и далее просто используются?

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

У Гугла есть компилятор шаблонов выполняющийся на клиенте, он использует Java (не путать с JS). Но собственно этого и не надо, все это с успехом можно на jQuery сделать.

<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Администрирование сайта</title> <hta:application id="myApp" applicationname="adminSite" version="1.0" border="thick" borderstyle="normal" caption="yes" icon="icon.ico" scroll="no" showintaskbar="yes" singleinstance="yes" maximizebutton="yes" contextmenu="yes" windowstate="maximize" selection="yes" innerborder ="yes" /> <meta http-equiv="MSThemeCompatible" content="Yes" /> <script type="text/javascript">     alert('Я есмь приложение')     </script> </head> <body>   <div>Использовать можно все, нет ограничений - считать шаблон страницы приложения, вставить в него данные полученные от сервера, это пустяк.</div> </body> </html>

Сохраните с расширением .hta и запустите.

Не обязательно приложение, а просто перевести все существующее на Ajax не такая и проблема.

Самый простой для освоения js шаблонизатор - это http://olado.github.io/doT/index.html

Не пойдет такой, если иметь ввиду приложение.

почему?

Во-первых, и это не касается приложения, в нем используется хорошая вещь, Node.js, а это далеко не jQuery, которое используют "абы как" потому как не знают JS, а используя Node.js, надо хорошо разбираться в Javascript.

Во-вторых, это "голый" компилятор шаблонов, а требуется нечто иное.

В третьих, для того о чем я говорил ранее, он совсем собственно и не нужен, а если бы лично я и пошел по такому пути, то все-таки использовал бы компилятор Гугла. Надо представлять себе задачу эту, тогда станет понятым, что в данном случае "натянуть шаблон", это не парсить в поисках {Х}, а просто напросто выполнить в подключаемом файле код, разделяя его на обслуживающий шаблон и на обменивающийся данными с сервером.

1. про NodeJS впервые читаю, ранее не видел его в тексте.
2. да, голый. но если задача состоит в том, чтобы получить от сервера данные в каком-то виде, а потом их передать в браузер через js, то вполне себе этот шаблонизатор справляется. я не агитирую за него, просто делюсь мнением.
3. если это NodeJS, то да - тут другое. но про него речь не шла. может, я что-то и упустил.

Если вы даете ссылку, то наверное же знаете что это такое, так что странно впервые слышать о Node.js.

>чтобы получить от сервера данные в каком-то виде, а потом их передать в браузер через js, то вполне себе этот шаблонизатор справляется

Для этого не нужно никакого шаблонизатора.

о NodeJS я знаю. я имел в виду, что он не упоминался в этом посте.
>Для этого не нужно никакого шаблонизатора.
А что нужно? генерировать хтмл на стороне сервера?

> о NodeJS я знаю. я имел в виду, что он не упоминался в этом посте.
Вы же сами его упомянули дав ссылку. )

этот шаблонизатор работает отлично и без nodejs.
doT.js is fast, small and has no dependencies.

Во-первых в браузер ничего через JS передать нельзя, JS может только обработать полученные от сервера данные (а доступ к ним дает браузер посредством DOM) должным образом и поместить их в требуемое место. Каким боком тут нужен шаблонизатор, если речь идет о передать-принять?

>Надо начать с азов ООП. тогда все вопросы отпадут. ООП в пхп. Потому как конструктор контроллера - это конструктор класса.

Зачем вы это советовали? Вы думаете именно это и надо для решения указанной проблемы? Какие глупости, вместо того чтобы правильно распределить приоритеты и по ним построить код, засесть в изучение ООП. ОПП, это не значит что пишем исключительно на нем, и все проблемы автоматом испаряются. Читаешь и диву даешься.

Ну хорошо, пусть сервер запарился с ОПП, а что на клиенте такого не может быть?

А если вообще абстрактно, то "конструктор", это не собственность ООП, и трактовать это понятие можно широко. Лего - конструктор, а еще в бывшей нашей необъятной выпускался с железочками в дырочку, винтиками и гаечками, это тоже конструктор.

Если генерировать HTML на сервере и передавать его клиенту, то какая речь вообще может идти о шаблонах на клиенте? А вот иметь основное содержимое на клиенте, которое принимает уже готовый html-код асинхронным обменом, это можно, так можно построить управление на Ajax.

Но говорим о шаблонах. А с чего начинается административный раздел - с данных, собственно с них все начинается. А данные это не только список пользователей или иной список, это еще и разделы сайта (его ресурсы).

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

Запрос, авторизация, если успешно, то загружается шаблон главной, далее весь обмен с сервером асинхронный. Каждый запрос меню определяет не только соответствующие данные от сервера, но и имя шаблона страницы загруженной в родительское окно под эти данные. Кроме этого определяется и тип данных - если запрос данных для шаблона, это данные шаблона, а вот запрос с уже загруженной страницы, это уже просмотр/редактирование/добавление данных на сервере.

А если захочется добавить новый ресурс "Сайки"? Значит шаблон родительского окна, это не html-код в котром прописано меню разделов сайта. Каждый раздел меню, это секция описывающая или готовую html-структуру, или html-элементы по которым будет построена структура. Вот этим элементам и нужны "голые" данные от сервера, а чтобы их отобразить на странице совсем не обязательно выискивать в строках что-то, проще иметь готовый код обслуживающий секцию (или типовые секции).

Тогда и не проблема добавляя данные серверу (новый раздел), сохранить созданный новый раздел как новую секцию в шаблоне, а исполняя управление сайтом как приложение, сделать это совсем не сложно.

А это тоже конструктор, как Лего - берем кубики и строим ... что необходимо, то и построим.

Большое спасибо за пояснения.

>А если асинхронный, то пофигу авторизован или нет?

Имеется ввиду, что если запрос к скрипту через аякс, то проверять в нём авторизацию нет смысла, так что ли?

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

Полный асинхронный обмен данными хорош тем, что почти в реальном режиме времени можно следить за изменениями в системе. Ведь не только администратор вносит изменения на сервер, инициатором таких изменения могу выступать и пользователи - оформился новый пользователь, поступил новый заказ/заявка и т.п. А ведь еще могут быть задачи, которые выполняет планировщик задач - рассылка новостей, удаление тех или иных записей по условию и т.п.

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

Спасибо. Да, выходит, у меня косяк вылез. Вернее как вылез. До того, как не было аяксов, и страница грузилась полностью, авторизация проверялась при каждой загрузке. А при аяксе на скрипты — не проверялось. Блин, и проект — динозавр, переделывать придётся много.

А вы случаем курсы для желающих не проводите?

Нет, только уроки бальных танцев )

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

Да. Всё ясно.
Тогда, если не возражаете, можно я вас ещё немного вопросами помучаю?

В качестве пролога — я раньше на всяких асмах-си-паскалях писал, жизнь заставила писать и под веб. Когда начинал делать сайт, толком ничего не умел, по ходу получения знаний занимался модернизацией. Потому мой проект сейчас как динозавр с куче костылей.

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

До недавнего времени (до начала использования аякса) я под каждую таблицу делал отдельный класс, который отвечает за работу с данными из этой таблицы. Ну, то есть, тупо выводил html по старинке. Потом, со временем, стал использовать автоматическую подгрузку данных в комбобоксы из других таблиц аяксом, и тут во мне закралось подозрение, что всю эту неуклюжую конструкцию (движок) можно как то упростить.

Вот вы тут написали очень правильные вещи, например, перевести админскую часть целиком на аякс, по нему же получая только голые данные и уже на клиенте их распихивать по формам-местам. Всё ясно, кроме одного — что же делать с этой кучей таблиц? Писать опять под каждую свой javascript код, или же есть методология, позволяющая шагнуть на встречу светлому будущему?

Ну, в качестве идеи вижу, например, такой вариант. Скажем, нужно отредактить описание объекта, тогда по запросу получаем, например, такой ответ:

{id:"1",
error : "0",
template:"person.tpl",
data: {
personID:"10",
personName:"Vasya",
personAge:"10",
}
}

где personID, personName, personAge — имена полей в БД, и они же ID полей, куда надо примостить данные. А примостить их надо в person.tpl, который, по логике, надо получить либо заранее, либо дополнительно запросить. Второй вариант, конечно, никудышный. В первом можно заранее вывести эту форму, но как быть, если, скажем меняется контекст, и нужно отредактировать другую таблицу? Придётся запросить таки новый шаблон, а потом в него данные, так что ли?

Что скажете, мастер?

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

В моём положении, когда проверка на авторизацию происходит только при загрузке страницы целиком, получается, что:
а) скрипт отрабатывающий аякс, должен сообщить, что сессия крякнула;
б) на клиенте это надо поймать и тупо перезагрузить страницу, типа window.location.href=window.location.href;

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

Какие вижу варианты? Можно создать (как — пока не знаю) некую обёртку, которая позволит выполнять аякс строго в одном месте, но отрабатывать успешное завершение, ошибки по разному, исходя из переданных в обёртку параметров. Это нормальное решение?

{.. template:"person.tpl"...} - а зачем клиенту ненужные данные? Если указывать клиенту куда это помещается, то получается, что инициатором диалога выступает сервер. Запрашивает клиент сервер, а не наоборот, а это означает, что клиент указывает серверу с каким шаблоном на текущий момент времени будет работа, и знает для какого шаблона данные ответа предназначены. Это если говорить о шаблонах на клиенте.

Не о шаблоне, сперва просто готовый html на основе таблиц базы.

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

Поля таблиц кроме данных могут иметь комментарии, а это значит, что указать заголовки таблицы которая выводит эти данные можно на основе этих комментариев. Число колонок таблицы определяется только числом полей которые необходимо просмотреть/обновить.

Поля которые обновляются имеют соответствующие поля формы, тип которых может быть основан на типах данных таблицы базы.

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

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

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

Все это вместе может работать как автомат, при этом не обязательно такое можно решить только в ООП. Если данные имеют простейшие индексы, то это уже позволяет ссылаться по ним как адресам в матрице, которая описывает имена, правила и прочее. То есть, в качестве такой матрицы может выступать обычный массив, а ячейка массива совсем не обязана содержать только число/строку, это могут быть и функции.

Я уже здесь писал о подобном с примерами, повторяться не хочется, а то что сделать можно, это бесспорно. Только для этого нужно отталкиваться не от {id:"1",..., pesonAge:"10"}, а от первичного - от данных, их организации, а что и как передавать клиенту, это уже потом.

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

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

Согласен.
А как быть, если разного рода связки вроде backbone и lavarel, которые возвращают данные из БД в чистом виде (видео)? Подобные связки используют же десятки тысяч людей, если не больше.

С одной стороны, выходит, безопасность, а с другой удобство и скорость разработки? (это я присматриваюсь к инструментарию, что бы в будущем динозавра своего переписать).

Вы хотите чтобы я это кино смотрел? У меня на данный момент времени нет времени на сериалы, да и вообще, уж если вникать в это, то по печатному оттиску.

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

Спасибо, камрад.

Да, js строит DOM на основе этих данных. Но, чтобы построить DOM, нужно эти данные представить в хтмл виде, так? Можно не использовать шаблонизаторы, а выдавать от сервера хтмл, но это не очень круто, так как передается много лишнего кода. ну, если сравнить html и json, то что будет "легше" передать от сервера к клиенту? к тому же эти данные могут понадобится для других целей, для отображения в другом участке сайта. заново писать серверный скрипт, чтобы он вернул те же данные, но в другом облачении? Нет, наверное..

Да, js строит DOM. Можно в самом js присвоить какой-то переменной хтмл и на его основе строить дом, но это ли правильно? тогда откуда брать этот самый хтмл? если с сервера не true (я имею в виду не с какого-то файлика, который лежит на сервере, а ответ на ajax запрос), то как тогда быть? вот тут и помогают шаблонизаторы. Да и отделение логики от представления не только в пхп должно быть.

Что касается ООП, то можно и без него, кто ж спорит-то. дело вкуса, практики и масштабируемости сайта.
Когда я говорил про конструктор контроллера, то имел в виду следующее. В конструкторе происходит, грубо говоря, проверка на существование сессии и того, что нужно проверить. когда происходит запрос в рамках фреймворка, то сначала вызывается конструктор контроллера. если в нем проверка не пройдена, то.. то нужно делать то, что нужно, вызывать окно с авторизацией и т.д. Но можно и без ООП обойтись. написать функцию в одном файле, которая возвращает что-то, true/false или айди юзера. инклюдить этот файл куда надо и пользоваться функцией для проверки. повторюсь, дело вкуса и задачи.

Если сайт имеет ресурсы "Булочки", "Бублики", "Плюшки", то серверный скрипт может отдавать данные для каждого раздела. И на основе этих данных строить ДОМ. Не вижу проблем с тем, чтобы не использовать шаблонизатор.

В общем сути писанного не понял.

А сим Если сайт имеет ресурсы "Булочки", "Бублики", "Плюшки", то серверный скрипт может отдавать данные для каждого раздела. И на основе этих данных строить ДОМ. Не вижу проблем с тем, чтобы не использовать шаблонизатор. Америку вы не открыли ибо я об этом и говорю, вопрос только как, и что понимать под "шаблон".

У вас какое-то однобокое представление о шаблоне.

Данные это 1, 2, 3, а шаблон, это шаблон некая абстрактная структура (ибо на html свет клином не сошелся), в которую нужно поместить эти данные. Но можно карячится вот так - /pattern/g.method(), а можно просто исполнять код.

можно и просто исполнять код. а дом как формировать? на основе объектов или откуда-то взять хтмл, подставить в него данные и вставить в нужное место сайта?

Забуривайтесь в DOM+JS, ответ находится там. Нет у меня времени чтобы пояснять вещи, которые описаны не на одном ресурсе.

HTML, который вам надо "взять", как раз и находится на клиенте, это и есть шаблон. Вот только это не страница <div>{var}</div>, это структура (кубики) которой управляет сценарий. Строили башни из кубиков в детстве? Значит вы конструировали. А так однобоко подразумевать "шаблонизатор" как вы его представляете, это не строить башню из кубиков, а пилить из бревна кубики, и только потом пытаться из них что-то построить.

так и я о чем. только этот <div>{var}</div> лучше не в переменной держать, а откуда-то брать, чтобы не мешать.. хотя ладно, мне уже надоела эта дискуссия.