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

Добавлено 1 день спустя:

Переварил. По большому счету тег-процессор можно оформить для Сиены в плагин. Что касаемо асслциации и прочего связанного с категориями, это плагин. В минимальном варианте работает. Однако, должно вылежатся (отлежатся). Имеется большая  перспектива этого направления. Нужно думать.

Вот и получается, что наряду с категорией надо вводить и ассоциацию.

Все равно не понимаю зачем. В вашем случае можно заменить: {{ДИАГОНАЛЬ}} на {{PAGE_DIAGONAL}}, что четко укажет на конкретное экстраполе.

з.ы. Добавил иллюстраций и пояснений в предыдущий пост. 

формат: {{ассоциация или имя тега}возможная замена сообщения}

Для чего нужна ассоциация. Она позволяет просто написать:

Размер телевизора по диагонали {{ДИАГОНАЛЬ}}

что даст отображение:

Размер телевизора по диагонали 61см

механизм позволяет интерпритировать ассоциацию с конкретным экстраполем.

Вот и получается, что наряду с категорией надо вводить и ассоциацию.

Вот пример функции для Генуи:

function тег_процессор			//	функция процессора тегов вида {{тег}аргумент замены для тегов, которые включают HTML тег А}
								//  аргумент замены для тегов, которые включают HTML тег А =значение необязательно
								//	В том случае, если имеется указание на то, что тег содержится внутри другого тега,
								//	то тогда из тега должен быть извлечен аргумент HTML параметр hreff и зменнет аналогичным из тега
	(
	$входная_строка=FALSE,		//@param string	- обрабатываемая строка
	$тег_в_якоре=FALSE,
	$tags
	)
{
global $cfg;

if	(empty($входная_строка)) return $входная_строка;

$голова='';
$тело=$входная_строка;

while(TRUE)
	{
	$найден_тег=FALSE;
	$это_меняем=FALSE;
	$это_заменяем=FALSE;
	$часть=preg_split('/\\{\\{\\s*([a-zA-Z0-9_'.$cfg['alpha_national'].']*)(\\})/ui', $тело,2,PREG_SPLIT_DELIM_CAPTURE); 
 	if	(count($часть) == 4)
		{
		$голова.=$часть[0];
		$найден_тег=$часть[1];
		$тело=$часть[3];
		$аргумент_замены=preg_split('/(\\})/ui', $тело,2,PREG_SPLIT_DELIM_CAPTURE);
		if	(count($аргумент_замены) != 3) break;
		$тело=$аргумент_замены[2];
		if	(empty($найден_тег) or !isset($tags->vars[$найден_тег]))
			{
			$голова .="{?{".$найден_тег."}?}";
			continue;
			}
        $найден_тег=$tags->vars[$найден_тег];
		$это_меняем=TRUE;
		if	(!$тег_в_якоре)
			{
			$ищем_якорь_в=$найден_тег;
			$это_заменяем=$часть[0];
			while(TRUE)
				{
				$порция=preg_split('/a\\s*(href)*\\s*\\=/ui', $ищем_якорь_в,2,PREG_SPLIT_DELIM_CAPTURE);
    			if	(count($порция) == 3)
					{
					if	(empty($порция[2])) break;
					    else $ищем_якорь_в=$порция[2];
					}
               	else	{$это_заменяем=FALSE; break;}
               	}
			}
		else if (!empty($аргумент_замены[0]))
				{
				$порция=preg_split('/(\>)/ui', $найден_тег,2,PREG_SPLIT_DELIM_CAPTURE);
                if  (count($порция) == 3)
                    {
                    $замена=preg_split('/(<\\/a|A>)/ui', $порция[2],2,PREG_SPLIT_DELIM_CAPTURE);
                    $найден_тег=$порция[0].'>'.$аргумент_замены[0].'</A>';
                    }
				}
        if	($это_меняем)
        	{
         	$голова .= $найден_тег;
        	}
		}
     	else break;
return $голова.$тело;
}

ключевая строка из page.main.php, строки 148, 149:

$mskin = cot_tplfile(array('page', $cat['tpl']));
$t = new XTemplate($mskin);

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

Тут, если я правильно понял, надо заводить соответствующее количество экстра полей для страниц, пример: razmer, data, ves. А в нужной категории в шаблоне page.cat.tpl использовать только актуальные для данной категории: {PAGE_RAZMER}, {PAGE_DATA}, {PAGE_VES}.

#34478 Sergey:

Как это пристыкывать я не знаю.

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

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

1. [Рассматриваем случай, когда нет возможности написать плагин под это дело, и обходимся только шаблонами. Т.е. то , что описано мной в первом абзаце].

Есть список товаров, разделенный по группам (пример: кастрюли, телевизоры). Каждый товар представлен собственной страницей, и хранит набор своих свойств в экстраполях: diameter - диаметр кастрюли, diagonal - диагональ экрана. Категория товара определяется том, в какой категории страниц находится товар (категории как обычно создаем через админку).  При создании страницы необходимые экстра поля заполняются. Тут даже можно создать отдельные шаблоны для создания страниц в каждой категории, тогда можно не отображать «ненужные» для данной категории поля свойств.

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

2. Вариант когда некий шаблон вывода данных мы хотим сохранять как страницу (и редактировать через Web). Тут без небольшого плагина не обойтись (назовем его условно pagetemplate).

Входные данные и структура сайта аналогичны предыдущему примеру. Экстраполя. Структура категорий. Структура товаров - пункт 1. Создаем отдельную подкатегорию tpl в категрии «system», где будут лажеть страницы-шаблоны (в таком случае простой пользователь не будет иметь к ним доступа) - пункт 2. 

Страница шаблон будет иметь формат данных аналогичный, используемому в строковых ресурсах. Т.е. это любой текст со вставками специальных тегов (типа {$size_value}), которые будут заменены на соответствующие значения. Псевдоним (alias) страницы будет соответствовать коду категории товара (для сопоставления шаблона нужной категории). В строке ключевых слов укажем через запятую названия дополнительных полей, которые хотим использовать в данной категории, например для телевизора «ves, razmer». Иллюстрация. Готовые шаблоны для разных категорий - илл.

Плагин будет работать просто - в шаблон отображения страниц ставим тэг {PAGE_TEMPLATE} илл. (прим.: на иллюстрации шаблон из темы HTMLKickstart), который плагином будет заменяться на соотв. кусок текста взятый из страницы-шаблона (выбранной по соответствию псевдонима коду категории). Перед применением страницы-шаблона, поменяем специальные теги на значения взятые из lang файла плагина и экстраполей страницы. 
Илл. (т.о. текст взят из страницы товара, а блок добавлен в соответствии с шаблоном). В другой категории будет использован свой шаблон.

Теперь поправим шаблоны добавления и редактирования страницы, добавив одинаковый тег {PAGE_TEMPLATE_EXTRAPARAMS} илл. (Прим. на иллюстрации шаблон из темы HTMLKickstart). Делаем это, чтобы при создании страницы в определенной категории, появлялись только определенные страницей-шаблоном (помните заполняли поле «keywords») для этой категории дополнительные поля. 
Т.е. (для примера) если мы создаем (редактируем) страницу в категории «Tv», то поля дополнительных параметров будут «razmer» и «ves», если в категории «phones», то параметрами будут «ves» и «color». илл.

Пример плагина качать здесь: http://www.cotonti.com/datas/users/pagetemplate_461.7z

Он проверялся под темой «HTMLKickstart», для другой темы оформления возможно потребуется немного изменить файл tpl/pagetemplate.tpl 
Ну и конечно это «пример на скорую руку». Так что никаких гарантий. :)

$mskin = cot_tplfile(array('page', $cat['tpl']));
$t = new XTemplate($mskin);

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

Как это пристыкывать я не знаю.

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

Добавлено 2 минуты спустя:

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

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

Не могу представить реальное использование. Можете привести пример?

1. блоки добавления данных (например в экстраполяхсбоку от основного блока. Удобнее тем, что не надо листать вниз страницу, а можно сразу добавить. (Если сбоку не получается/не удобно - как вариант можно сделать блок наверху страницы). Аналогично в редактировании структуры (страниц, форумов) блок добавления должен быть «под рукой» (сбоку или сверху).
Иллюстрация

2. В выпадающих списках сделано разбиение по категориям
Иллюстрация

3. Многие формы (для ввода данных) удобно скомпанованы, как пример форма добавления группы пользователей или форма добавления экстраполей:
Иллюстрация

Надеюсь, что-нибудь будет «одобрено» и внедрено в Priori.

на главной странице в блоке «настройки сайта», слово «сайта» уезжает вниз. Можно просто поставить overflow:hidden - останется только настройки (илл.6)

Где ты такие разрешения экранов видел (не счтая девайсов)?:)

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

+

Явных багов не заметил, но как всегда есть «замечания и предложения»:

• есть пожелание текстовые ссылки все-таки выделить подчеркиванием (как это обычно принято), например в разделе модулей/плагинов илл.1
• там же, можно продублировать ссылку иконкой илл.1, т.е. чтобы клик на иконке дублировал клик на название плагина
• для маленьких разрешений можно скрывать малоинформативные колонки в таблицах (для экономии ширины), например илл.2
• для узких экранов надо доработать стили полей ввода (и уменьшить их где необзодимо), илл.3
• замечательная идея мини-кнопок (с иконкой) для малых экранов. У меня немного торчит текст илл.4. Кстати в остальных разделах (в плагинах, правах пользователей и т.п) тоже надо это внедрить.
• в структуре категорит, первое поле не выровнено по вертикале. И (как писал выше), хорошо бы «укоротить» поля ввода.илл.5
• на главной странице в блоке «настройки сайта», слово «сайта» уезжает вниз. Можно просто поставить overflow:hidden - останется только настройки (илл.6)
• в идеале, хорошо бы варовнить текст по вертикале на плашках-кнопках илл.7. это уже мелочи, но все же «глаз» цепляется.

зы. Кнопка «опции» (выбор разрешения экрана) тоже приятное дополнение. У меня она только на самом широком экране, возможно стоит ее сделать на всех (или почти всех) «ширинах».

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

про пункт 1 я еще футер не крепил - это предстоит. 2 вот его не заметил -исправлю. 3 - согласен. 5 тут на главной все поменяется я хочу там сделать dnd технологию

Добавлено 3 дня спустя:

рассмотрел все возможные админки различных cms - пришел в выводу 99% не имеют какой либо удобной структуры. Все позиционируется на привычках

выводы:

- органичить ширину инпутов
-фиксировать тексты
-полное пояснение к плагинам
-посвечивать переменные в конфигах

Наиболее интересные админки:

ModX revolution

Kojana

Drupal 7

Wordpress

Добавлено 2 часа спустя:

несколько обновил

Добавлено 6 дней спустя:

снова обновление всех элементов

Вот несколько замечаний/предложений (поведение аналогично для ФФ и Хрома): 

• при разрешениях 1152-1680px закладки «Админ» и «Cotonti» открепляются от нижнего края илл.1, а на главном окне они «оторваны» почти постоянно илл.2 
• при разрешениях 1152-1680px закладки перестают работать (не подсвечиваются при наведении, нет возможности «кликнуть»): илл.3
• при разрешении 992-1152px в вернем меню иконка «просмотр сайта» на кладывается на «название сайта»: илл.4 (есть предложение в этом разрешении оставить что-то одно, т.к. функционал у них один и тот же).
• в главном окне есть предложение немного поменять ширины блоков - уменьшить левую колонку и увелисить правую. Тогда на маленьких разрешениях они будут смотреться лучше. илл.5

$cfg['admintheme'] = 'priori';

Хотел еще в Хроме глянуть, но обновил файлы движка до актуальной из Гита, и теперь штатная админка вернулась. Как включить Priopi обратно? (файлы не менял, так и лежат в themes/admin/priopi )

там появился элемент адаптивности... но чтото он не красиво сработал

В ней действительно переделали основное меню ? Или у меня глюк?

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

См. скрин

Добавлено 1 час спустя:

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

http://www.cotonti.com/datas/users/11_37.png

Юзабилити - в больших таблицах, когда курсор находится на строке и она выделяется цветом от остальных, намного легче ориентироваться (к тому же при full-screen).

оптимизовать классы - не согласен категорически. потом ищи что есть с и a d f и тд

А зачем выделять активную строку?

Да есть дилема: структура - лучше вывести все колонки и делать горизонтальный скрол или адаптивно скрывать все ненужные ячейки?

Еще как вариант, можно разные уровни вложений на разных страницах

Добавлено 3 минуты спустя:

Но лучше все ячейки показывать

Добавлено 3 минуты спустя:

Адаптивность меню - хорошо, но когда оно вверху, лечше пусть всегда будет текстом, ИМХО.

Добавлено 3 минуты спустя:

В таблицах еще не плохобы сделать выделение активной строки.

Добавлено 3 минуты спустя:

И мне не понятно, для чего в админке мета теги кейвордс и т.п.?

Добавлено 4 минуты спустя:

И было бы не плохо оптимизировать классы, например, вместо centerall - c, это заметно уменьшит код.

Добавлено 4 минуты спустя:

А структура в мозилле до сих пор притормаживает)

Wadik -смотри тему только на текущем гит срезе.

Добавлено 1 час спустя:

буду благодарен вашим вамечаниям. оптимизации ваши присылайте прямо в гит

http://www.cotonti.com/datas/users/1_37.png

http://www.cotonti.com/datas/users/2_37.png

Добавлено 1 день спустя:

движуха идет

https://github.com/esclkm/priori

собираем сами)

теперь появился элемент адаптивности - не судите строго

#33985 Fox:

Вот примерчик как верстают themes.kopyov.com/crown/

За такое и денег не жалко отдать =)

http://themeforest.net/user/Kopyov/portfolio - и очень многие так и поступают ))) я бы тоже с удовольствием отдал

А ещё глядя на количество заплативших захотелось стать верстальщиком .....

Вот примерчик как верстают themes.kopyov.com/crown/

За такое и денег не жалко отдать =)

Добавлено 8 минут спустя:

мне такое больше нра: http://elvery.net/demo/responsive-tables/

Мега пример верстки таблиц под адаптивный дизайн:
http://css-tricks.com/examples/ResponsiveTables/responsive.php

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

Здесь описание (на английском) : http://css-tricks.com/responsive-data-tables/

См. иллюстрацию

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

а вот в отношении с responsive версткой очень интересно но кака осущиствить ??? (фрейворки нашел... красиво... интересно.... но в живую этого не вижу

http://habrahabr.ru/post/141059/

а вот в отношении с responsive версткой очень интересно но кака осущиствить ??? (фрейворки нашел... красиво... интересно.... но в живую этого не вижу

Добавлено 13 минут спустя:

Значки проверено не выход... они обладают слабой когнитивностью что ли.... именно поэтому от них отказались