Применение шаблонов в случае XML\XSLT для "больших" порталов и не только

[dimgel]

У этого варианта есть один наисерьезнейший недостаток: он не пахнет инкапсуляцией.

Если мне приспичит переделать локализацию с использованием базы данных и php:functionString(), я буду вынужден изменять все вызовы, вместо того, чтобы изменить только реализацию своей функции-шаблона localize.

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

 

[Alexandre]

Народ, было бы просто замечательно, если бы в одном из ближайших выпусков кто-то взял на себя труд, написать статью именно но "теории" проектирования именно xml\xslt CMS!

Не надо путать божий дар и яишницу. Теория проектирования -это одно, использование шаблонизации - это другое. Использование xml\xslt - это как один из маленьких частей большого проекта, названный CMS.

И если кто-то говорит, что у него based xml\xslt CMS, то это только исключительно пиар. У меня был разработан фреймворк - аля based xml\xslt. Но что я про него могу сказать, из xml\xslt там использовалось только "банальное описание конфигурации фреймворка" (кстати не хилое...).
Пару слов о технологии (это уже обсуждалось в одном из топиках):
- структура МВСи описывалась в терминах xml
- все экшены описывалась в терминах xml
- движок состоял из парсера конфига и собственно самого движка (контроллера).
- парсера конфига отрабатывал единожды (например из админки ) и из based xml конфига строил php-код (конфигурационный массив) используя XSLT.
- контроллер, при активации скрипта, анализировал сгенерированный php-код и разруливал экшены, вызывая тот или иной класс модели. Потом отрабатывал - класс представления.

Можно ли назвать такой подход based xml\xslt - я не знаю? xml - используется только как наглядное представление конфига.

Что касается шаблонизации, то у меня мог подключаться принципиально любой шаблонный движок (при написании соответствующей обертки). В стандартном варианте я мог использовать как смарти, так и xml\xslt шаблонизацию (первоночально было выбрано второе).

Говорить, о based xml\xslt ЦМС, надо понимать - что мы под этим понимаем. Для меня - это, пока, пустой звук.

 

[vb]

Народ, было бы просто замечательно, если бы в одном из ближайших выпусков кто-то взял на себя труд, написать статью именно но "теории" проектирования именно xml\xslt CMS!

Не надо путать божий дар и яишницу.

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

 

[Alexandre]

Сначало написал бы кто-нибудь статью про просто теорию цмс...

CMS Bible видел на русском языке в наших магазинах.

 

[inTox]

Предлагаю забыть про термин "xml\xslt based CMS" или впредь всегда уточнять что именно имелось ввиду, когда разговор о CMS: xml\xslt based? smarty based? mysql based? php based?
CMS — сложная система, агрегирующая произвольные разнородные данные известных типов средствами управления и вывода. Основная задача XML как метаязыка для описания данных в "php based CMS" как раз в фиксации агрегированых данных (уже полученных и обработанных самой системой) перед выводом в клиент (с применением xslt процессора).

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

Большое значение имеют два вопроса "платформа?" и "характер данных?", а вопрос "как?" — рассматривется отдельно. Хотите использовать XML в качестве внутренней модели данных в системе - пожалуйста. Хотите грузить инструкции контроллеру и вызывать методы - на здоровье. SOAPDispatcher — флаг в руки. Попробуйте, начните. У Вас появятся конкретные вопросы на которые есть конкретные ответы. И про теорию проектирования тоже много написано, есть паттерны, в конце концов.

 

[Alexandre]

Большое значение имеют два вопроса "платформа?" и "характер данных?"

inTox а вот можно с этого момента по подробнее....

ИМХО я всегда считал, что ЦМС должна быть кросплатформенной или о какой платформе здесь идет речь? непонятки.

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

 

[inTox]

ЦМС должна быть кросплатформенной

не должна.

"характер данных"

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

 

[Alexandre]

Если писать не "универсальную цмс с единым интерфейсом" а движок для конкретных нужд - это быстрее становится понятным

согл. есть много особенностей у каждого клиента, и мое мнение, что ЦМС затачивать под коробочный продукт - бесполезно.

ЦМС должна быть кросплатформенной
не должна.

почему?

 

[inTox]

почему?

- неправильно. Почему должна?

 

[dimgel]

Имхо кроссплатформенность зависит только от выбранного языка и библиотек. PHP, MySQL, XSLT - вещи достаточно кроссплатформенные

 

[inTox]

достаточно

для "hello world"? может быть. А вообще сам факт существования раздела http://phpclub.ru/talk/forumdisplay.php?s=&forumid=25 говорит об обратном.

 

[dimgel]

Львиная доля тем в том разделе - это ловля багов. Это не вопрос кроссплатформенности сайтов вообще и CMS в частности, это вопрос кривой реализации самих средств под виндой. Тот факт, что у меня под WinXP каждый второй SSL-запрос (HTTPS) рушит Апач, может судить о моей криворукости как админа, но мои сайты не становятся от этого менее кроссплатформенными.

А существенные для функционирования сайта отличия в хост-системах должны (по идее) инкапсулироваться в отдельные модули.

 

[inTox]

это вопрос кривой реализации самих средств

дык елы-палы, кроссплатформенное приложение это не должно учитывать? А когда Ваша кроссплатформенная CMS, написанная суперкроссплатформенно откажется работать Вы будете что делать? Чинить CMS или платформу?

 

[dimgel]

Вопрос хороший, но ответ будет зависить от ситуации. До сих пор единственная серьезная проблема, с которой я сталкивался в плане кроссплатформенности, - это Apache vs IIS. Ну, я её для себя решил, отказавшись от IIS. Впрочем, данный пример как-раз и показывает, что Ваша точка зрения вполне аргументирована.

Похоже, я лучше пока помолчу-послушаю.

 

[Alexandre]

- неправильно. Почему должна?

может что-то резонное в этом есть. Если ЦМС затачивется под особенности клиента, следовательно ЦМС затачивается под особенности хостинга, следовательно - кросплатформенность не нужна.

Однако - если делаем универсальный коробочный продукт, то кросплатформенность - это одно из условий (Должно работать везде и надежно!!! )