Меню
Что нового?

CMS - проектирование системы парсинга блоков

t3[0one]

t3[0one]

Новичок
CMS - проектирование системы парсинга блоков

Имеется 1 основной шаблон со строгой структурой.
Задача реализовать систему парсинга блов ,реализовать парсинг в любое место шаблонов блока, в зависимости от используемого раздела проекта сделанного на кмс.
Разделы проекта строятся на NestedSet
Идеи .
Реализовать универсальность из 1 шаблона не пришло в голову. (любое место и тп )
Но вот что пришло в голову:
К создаваемому разделу присваиваются блоки , которые в свою очередь вставляют свои шаблоны в нужные «слоты» из конфига раздела. Слоты – места в в основном шаблоне , с присвоиными id.

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

На сколько это бреет или вообще что то придумать другое .. ваши идеи !))
 

Нечто

Психолог РНРClub
Не в тему, но на кой вам такая ригидная блочная структура?
Слишком много сущностей: слоты, блоки, конфиги...
 
t3[0one]

t3[0one]

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

-~{}~ 11.10.05 23:18:

пример с пхп нюк не годится не куда.

-~{}~ 11.10.05 23:46:

ЗЫ
все тяготы нагрузок на сервер я ложу на вроде хорошо отлаженое кеширование html кода .
 
_CMD_

_CMD_

Новичок
Можешь шаблон реализовать через смешанный xsl (html+xsl+собственные теги). Так вот эти собственные теги и будут отвечать твоим задачам куда угодно и что угодно можно ставлять и при помощи DOMDocument все простенько парситься заменяеться и тд...очень на мой взгляд просто в администрировани дальнейшем... и программиста не надо если что поменять на сайте... а простой верстальшик сможет справиться
 

No_name

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

PHP: 
abstract class Page extends Action {
	protected $components= array();
//$components - Массив, список компанентов вида: $components[Место] = Имя компонента
	protected $document = null;

//ф-я onInit() инициализация Page, вызывается до метода process()
	function onInit() {		
                	  $this->loadConfig();
	}

//ф-я loadConfig() грузит из конфига список дефолтных компонентов.
//реализуется в потомках т.к. загрузка этого списка может происходить из разных источников...
	function loadConfig() {
		
	}
//addComponent добавляет или перезаписывает имя компонента в списке
                function addComponent($place, $name) {
	     $this->components[$place] = $name;
	}

                function addComponents($components) {
	     $this->components = $components;
	}

                   .
                   .
                   .
                   . 
                   .
//Здесь мы создаём наши компоненты, выполняем и пишем их HTML представления в шаблон. 
	function process() {
	  foreach($this->components as $place=>$componentName) {
        $class = new ReflectionClass($componentName);
        $component = $class->newInstance($this);
	    $component->onInit();
	    if($component->accessLevel<=$this->accessController->getAccessLevel()) {			
	      $component->process();
	      if($cb = $component->getBody()) {
	        $this->document->assign($place,$cb);
	      }
	    }
	  }	
				
	  $this->document->fetch();
	  $this->getResponce()->setDocument($this->document);
	}
}
PHP: 
//класс PMain общий для всех страниц, здесь мы устанавливаем основной шаблон, содержащий разметку. (т.е. места куда будут вставлены компоненты).
//Здесь же мы реализуем метод loadConfig();
abstract class PMain extends Page 
{	
	
	function onInit()
	{
		parent::onInit();
		$this->document = new HTMLDocument();
		$this->document->setTplName('main.tpl');
		$this->document->assign('lang', 'rus');	
	}	
  }
  
  function loadConfig() {
		$rc = new ReflectionClass($this);
		$path = dirName($rc->getFileName());
		if(file_exists($cf = $path . '/.'.$rc->getName().'.config')) {
			$propertys = parse_ini_file($cf, true);		
		} 
		elseif (file_exists($cf = $path . '/.config')) {
			$propertys = parse_ini_file($cf, true);		
		}
		
		$this->addComponents($propertys['components'] );
	}	
}
PHP: 
//Непосредственная реализация странички, здесь мы только добавляем имена компонентов к списку
class PMNews extends PMain {
	
	function onInit() {
		parent::onInit();			
		if($this->getRequest()->getParameter('id')) {
			$this->addComponent('center', 'CMNews');		
			$this->addComponent('right', 'CMNewsList');
		} 
		else 
			$this->addComponent('center', 'CMNewsList');
	}
}

P.S. За основу движка, взято freeform framework и соответственно класс Action тоже от него.
 

liss

Новичок
Скажу что я для своей реализации пользовал Смарты - очень удобдо и просто.
 
t3[0one]

t3[0one]

Новичок
я тоже использую smarty, только это к теме не относится.
Впринцыпе не стал сильно извращатся. Все сделал через wysiwyg, что и предало гибкость, и простоту в эксплуатации.
,Возможно использования n-ого колличество макетов в одном проекте
 

liss

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

Z3X

Новичок
Народ немножко отступая в сторону от темы... Сколько запросов у вас выполняется например при генерации index page? Я просто тоже свою CMS пишу вот по поводу нагрузки волнуюсь...
По пододу шаблонов я сначала придумал систему которая при обработке шаблона обраатывала так называемый MiltiInclude, который позволял "подгружать" блоки с разными шаблонами в определенное место на странице, а потом отказался и решил что динамическое создание блоков вообще не нужно ;)))
 
t3[0one]

t3[0one]

Новичок
1 запрос на получения данных о блоках и модуле на страницу,далее запросы самих модулей и блоков. 5-10-20 запросов ,в зависимости от используемого модуля и блоков, на генирацию кеша для группы пользователей.
 

Alesto

Новичок
Господи, как у вас все сложно-то, а не вариант делать шаблоны, навтыкать туда тегов в стиле XML, и разобрать PHP-шником как надо (на примере реализации XML Sapiens).
 

alexhemp

Новичок
С.
Человечище, ты вообще понимаешь зачем нужны шаблоны? Простой PHP скрипт выводящий строку из базы - уже содержит в себе "шаблон" вывода.
 
С.

С.

Продвинутый новичок
Я понимаю, зачем нужны шаблоны.
Я не понимаю, зачем нужен излишний парсинг.
 
t3[0one]

t3[0one]

Новичок
http://zero1.ath.cx/upload/download.php?id=3f4d38a7f2fdc9c3794ed091b0898779

от что то кривое получилось (видео делал давно ,за ошибки извенити) На пример по вставки одного модуля (с причетающимися ему шаблонами) ! Все на Smаrty тегах, без xml и дополнительных плагинах Smarty.

Зачем нужно ? на мой взгляд просто в использовании и верстке + без замарочек с кешированием и тп . И лишнего нету ничего вроде . Минимизировано вроде бы .

PS вообще модуль и блок слились в некую единую сущность.
 

alexhemp

Новичок
С.

Я уже писал неоднократно - затраты на компиляцию шаблонов (да-да шаблоны в нормальных шаблонизаторах компилируются в php-код) - ничтожны по сравнению с увеличением скорости разработки и улучшением качества кода.

Если следовать твоим рассуждениям - php вообще не нужен, в нем сплошной парсинг. А нужно тогда писать на ассемблере или в крайнем случае на C.
 
С.

С.

Продвинутый новичок
alexhemp

Извини, я наверное косноязычен. Мне не понятно, зачем парсить что-то в PHP код, а потом этот PHP код парсить еще раз. Два (2) парсинга получается (первый из которых, как правило, самодельного сомнительного качества, с ограниченными возможностями). В то время, как можно выполнить две разделенные задачи (шаблонирование и логику) всего за один проход PHP. В той системе, на которую я указал (www.phella.net), как раз так и делается.
 

master_x

Pitavale XXI wieku
С.
первый из которых, как правило, самодельного сомнительного качества, с ограниченными возможностями
Нажмите для раскрытия...
вы не правы, Смарти к примеру довольно развитая система далеко не сомнительного качества. И использовать с ней можно хорошие шаблоны.

alexhemp
Если следовать твоим рассуждениям - php вообще не нужен, в нем сплошной парсинг. А нужно тогда писать на ассемблере или в крайнем случае на C.
Нажмите для раскрытия...
Нельзя так утрировать.
Человек задал вам правильный вопрос, а вы писали:
с увеличением скорости разработки и улучшением качества кода
Нажмите для раскрытия...
это же получается, что шаблоны написанные на pure PHP- написанны медленно и качественно на порядок ниже чем шаблоны на Смарти? Неправда.
Не надо разжигать войн. Тут действует принцип "кому как удобнее и привычнее" а не "это лучше а это хуже"
 

alexhemp

Новичок
С.

Утирирую опять: Зафига юзать какой-то php в который будет все время что-то парсить если можно все написать на ассемблере?

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

Касательно твоего примера - то что в качестве "шаблона" можно использовать php-файл очевидно и понятно.

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

master_x
Утрирую я сознательно. Reductio ad absurdum, так сказать.
И не разжигаю никаких войн. Просто опыт показывает что разделить данные и их представления без использования специализированных систем управления шаблонами трудно. Соблазн вставить "для скорости" в середину шаблона запрос к базе остается велик :) А уж если работает несколько человек - то бывает разное, даже если квалификация высока.
 

master_x

Pitavale XXI wieku
alexhemp
Соблазн вставить "для скорости" в середину шаблона запрос к базе остается велик :)
Нажмите для раскрытия...
а вот это уже явно не относится к шаблонам и чистому PHP. Плохой пример.
 
Войдите или зарегистрируйтесь для ответа.
Сверху