Леша, глянь как на проделанную мной работу в последнем ее варианте. Это шаблонизатор, который должен стать универсальным. Его идея - всего одно правило - синтаксис шаблона. А уже как ведет себя тот или иной блок или команда - это зависит от того. как мы напишем этот обработчик. Кстати, расширяется он на ура - просто и элегантно.

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

Адрес проекта http://http://code.google.com/p/templum/

Мне показалось или в некоторых классах singleton'ы по разному называются...? singleton, init или run

{include file='test2.html'}

Я бы написал

{include 'test2.html'} - как и в PHP...Поддерживаются только одинарные кавычки или двойные и `

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

Саня, можно кавычки писать любые.

Спасибо за то. что уделил время просмотру кода. Ты прав, где-то я пишу run(), где-то singleton(). Но суть одна и та же.

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

Т.е. можно написать так:
{include 'test2.html'}
и в обработчик include передастся массив переменных array(0=>'test2.html')

Хорошо, твой подход имеет право на воплощение. Давай перепишем главное правило парсинга шаблона.

Еще хочу заметить что фильтры сейчас не поддерживаются. Т.е. нужно добавить парсинг еще вот таких конструкций
{$var|crop len=10 end='...'|escape}

Это делается путем разбиения одного правила в пределах {...} на ряд последовательности правил, отделяемых друг от друга вертикальной чертой "|".

Как мне видится, это будет как раз то, чего хотят люди от хорошего шаблонизатора.

P.S. В ближайшие пару недель я буду занят другими задачами, поэтому предлагаю тебе взяться за доработку этого шаблонизатора. Будут вопросы - спрашивай, я всегда отвечаю. Спасибо за твой труд!

Да, и еще. Сейчас есть исключение из правил для {...}. Если чтоит первый символ знак доллара, то подставляется вызов функции var value=$var. Как я заметил сейчас, можно так же применять это правило в тех случаях, если первый символ после "{" является $ или кавычка (строка в кавычках).

Этим самым мы сможем писать вот так:
{'This test show for you'|crop 10|escape}

{$var|crop len=10 end='...'|escape}
Не красиво)
----
Можно пробовать взять за основу альтернативный синтаксис PHP, но без
<?php ... ?> "PHP-кавычек"

<?php if(true): ?>
...
<? endif; ?>

В шаблонизаторе сделать

if(true):
...
endif;
---
Во фреймворке сделан роутер? Разбирает урл и вызывает нужный контролеер, дествие, может модуль(несколько контроллеров для одной цели... форум к примеру)
---
Ну и то, что singleton'ы по разному называется это большой минус, приходится помнить у какого класса какой. Я сам привык к имени getInstance
---
Насчет кавычек...пол года назад решил для себя использовать только одинарные кавычки в PHP. Немного ухудшается читабельность,но скорость возрастает. Фреймворк не для чтения, а скорость важна...думаю стоит задуматся...пусть это копейки...но нужно выжимать максимум...
---
Сейчас фреймворк похож больше на набор библиотек...можно сделать такую мега-вкусняшку...сделать инсталятор на PHP или в виде отдельной программы...запускаешь его, выбираешь нужные библиотеки(шаблонизаторы к примеру), там настраиваешь конфиги, добавляешь контроллеры и действия(actions)...указываешь папку куда сложить эту вкусняшку и 20-30% сайта уже готово...

Синтаксис выработан не одним годом практики. и путем экспериментов и изучения шаблонизаторов на многих языках. Были столкновения к трудностями, которые привели к тому решению, которое показал я выше.

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

Можно стандартизировать имена методов. Но getInstange пахнет МелкоМягким синтаксисом, который я не люблю.

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

Уже ведется разработка генератора кода. Но сейчас уже Вы можете им воспользоваться и описать свои предложения по его доработке.

Успешного изучения!

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

И чем тебе не нравится getInstanсe?) Многие ООП программеры используют singleton, но из них меньшинство знают, что это называется singleton

Так более менее-понятней, вернуть экземпляр...

http://http://www.phpro.org/ Автор использует getInstanсe кстати...и глянь он разрабатывает фреймворк...я бы назвал что-то среднее между фреймворком и CMS