Давайте может исключительно XML+XSLT использовать? Т.е. выдаем весь контент в XML всегда. И всегда для него есть конкретный XSLT-парсер.

Судя по всему при таком подходе нужно будет создание большого кол-ва XSLT парсеров, однако я думаю это не проблема. Люди у нас есть.

Проблема заключается в другом - в рациональности такого подхода. Ведь когда нужно что-то простое вывести на экран гораздо проще вывести сразу HTML, а не раздельно XML и XSLT. Что думаете по этому поводу?

ИМХО ничего страшного в разделении для "простых" вещей нет. А ХТМЛ всегда и так можно выдать.
Делйте сразу XML / XSLT и желательно с клиентским парсингом. Быстрее, надёжнее, правильнее.
Добавлено @ 20:34
Во всяком случае этот подход будет являтся коренным отличием от всех остальных CMS.

Да,. я вот тоже так думаю... Парсинг конечно я бы тоже переложил на клиента. Есть такая система: SiteBuilder. В ней используется также XML и XSLT, однако парсинг на сервере они почему-то делают. Почему - это большой вопрос...
Добавлено @ 20:38

Именно. Имеет смысл делать CMS, только если с самого начала сейчас ее начать строить на новых технологиях. Что и хочется сделать. Очередной клон какой-то CMS cмысла создавать нет. Поэтому я предлагаю с самого начала все МАКСИМАЛЬНО продумать и задукоментировать ядро системы.
Так, чтобы любой разработчик мог легко писать к ней модули.

Потому что не все браузеры поддерживают. Точнее опера < 9.0 не поддерживает. Вот для них можно на сервере делать.
К тому же технология вообще не широко применяется, потому что очень новая. Но практика показывает, что это всё прекрасно работает.

Вот тут есть данные о поддержки браузерами: http://www.w3schools.com/xsl/xsl_browsers.asp

и тут: http://svn.code-host.net/browser-tests/
Добавлено @ 21:00

А насколько это сложно на сервере делать?

Вот к этому надо подойти очень ответственно!!!

Так.. А что делать с шаблонами и шаблонным языком? Если мы используем XSLT, то нам вообще не нужен никакой шаблонный язык больше??

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

Для простых вещей можно внести в Framework простой шаблонизатор, для подмены пары значений в HTML.

Отлично! Как с твои классом можно будет работать? Может какой интерфейс использовать?

Wowa, с моими классами работать нельзя будет. К сожалению в РНР 5 из екстеншина DOMXML исключили функции отвечающие за xslt преобразования. Сейчас начал переписывать под 5 -ку для ext. DOM.
Работа класса несомненно будет строиться на интерфесах. Мне очень это помогло с DOMXML. Сокращает объемы кодинка во много раз.

интересно, почему...

Wowa, видимо из-за некоторой несовместимости DOM и DOMXML в РНР 4 и 5. Предпологаю что из-за того что и DOM и DOMXML используют одну модель для работы с XML данными, и эта модель различается в разных версиях.
Хотя может я не подключил какие-то либы у себя... я своего хостера просил поставить для 5ки DOMXML, пока не сделали, сказали позже отпишутся. Если поставят и там будет работать, значит я чего-то не до подключил.
Добавлено @ 23:52
Насколько я понял из мануала, в РНР 4 использовать нужно класс XsltProcessor (http://php.rinet.ru/manual/ru/function.domxml-xslt-stylesheet-doc.php).

Wowa, 
Не нужен никакой класс, все делается через extension: http://ee.php.net/xsl

Это и есть XSLTProcessor о котором я говорил) екстеншн в виде класса.

Используем DOM + XSLTProcessor и проблем не будет.
В некоторых случаях обработка на сервере будет не нужна, все будет зависить от поддержки XSLT преобразований клиентом.

Ребята, а как мы будем делать, например, веб-ссылки в XML-документах? Ведь disable-output-escaping в Firefox не поддерживается...

Wowa, ты о том что в URL'ах & будут заменяться на &amp;? Так PHP уже давно сие понимает правильно.

Не, я про то, что если в XML написать:


А в XSL написать:


то посетитель увидит в браузере просто надпись "http://vingrad.ru", которая не будет являться гипер-ссылкой.

А если написать так:


то в IE это отобразится нормальной ссылкой, а в Firefox будет &lt;a href='http://vingrad.ru' &gt;vingrad&lt;/a&gt;

Wowa, странно, не встречался...  А зачем отдавать ХHTML вот так? Почему не просто элементами <a href... />?  Если это в данных, то на кой использовать трансформации, если данные уже отформатированны. Хотя придумывать  свою разметку глупо, просто её нужно немного ограничить, что бы можно было сконвертить в XSL-FO по требованию.

Вроде нельзя из-за < и >, т.к. испорится структура XML. Или?

А почему она должна испортиться? Если конечно только схема не позволяет разметку, но тогда что в элементе делает разметка 

XML  в XML не надо оборачивать/экранировать, просто нужно следить что бы вёрстка была валидной XML(XHTML) и при переносе в конечный документ переносить всё поддерево, а не "только текст".

Сардар всё ответил   output-escaping нужен для контента, который неизвестно откуда пришёл. А если сами формируем ХМЛ, то просто не надо структуру ломать и всё будет ок 

хорошо

Wowa, 
http://www.activsoftware.com/code_samples/..._XML_Validation ?

Wowa, на то чтобы ссылки отображались нормально, нужно чтобы документ был частью XML, а потом делать просто copy ноды с документом.

Ок, всё вроде решили.

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

Если кто-то возразит "а зачем нам так гибко?", то тогда я возражу, а зачем вам тогда XML, как не для гибкости представления контента с последующим рендерингом во что угодно (99% времени XHTML) 
ИМХО есть большая разница, между генерацией страниц (что содержат кучу инфы) и XML сервисами, которые генерят только то, что запросили. Первое можно генерить как угодно, но не стоит для этого сначала делать один большой XML, проще разбить на куски и генерить вёрстку каждого любой техникой, шаблонами в том числе.

на счет xml/xslt дел хорошо поспрашивать тех кто реально профи во Flex
адоб же придумала свой стандарт для XML ну тоесть на базе XML
я говорю про MXML. В описании этого языка,я думаю, можно найти ответы на 100 воросов вперёд которые могут возникнуть у Вас в процессе.


КСТАТИ!!! а как на счет 2-х не маловажных вещей:
1)система должна(мне кажется) одинаково работать как с обычными сайтами так и с флэш сайтами.
тоесть можно для тех ХМЛ схем которые вы напишете и которыми будуте оперировать написать Пару классов/компанентов для парсинга их флэшом.
2)Мне кажется если эта система - серьезная будет тогда не нужно думать о там что она сможет работать на любом хостинге, мне кажется что под серьезную систему должен быть предоставлен хостинг вместе с ней встроенный чтобы сорцы наруки никому не давать, а то zend ломать уже почти все научились так как пользуются дешовими старыми версиями.
Соответственно если для системы будет свой сервер то можно вытварять что хошь!!
тоесть чтобы систему можно было расширять во все стороны а не только по скриптовой линии.
чтобы вплоть до железог поддерживала итд.
Чуете чем пахнет? Одна система для управления персоналом работы сайта и учета рабочего времени.
ХАХАХХАХАХА  

че-то меня понесло..
возмите в разработчики а? я с алгоритмами и оптимизацией помогу =)
кстати вот тут попытка сделать такую систему о которой выше говорил
флэш презентация
http://www.artfabrique.ru/eva/eva_presentation_small.rar

>одинаково работать как с обычными сайтами так и с флэш сайтами.
Можно как плагин и это на будущее.

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

А как тут Flex поможет?

А смысл? Сервис должен отдавать минимум инфы, конкретно то, что запросили. Зачем генерить объёмный документ со всей лажей, типа менюшек (не зашивать же их в стили)? Если кто так делал, поделитесь с народом как галимо это было, только честно 

Вебсервис должен уметь отдавать только требуемую инфу в XML/JSON. Движок должен генерить полноценный XHTML документ (траф экономить на вёрстке это не разумно, нужно хорошо верстать  ). Документ собирается разными компонентами, которые могут использовать для своих частей всё что угодно, от темплейтера, до XSLT.

Т.е. всё на стороне сервера ты предлагаешь делать? Т.е. не доводить до преобразования до XSLT  на клиенте(браузере)? Какие аргументы против у тебя?

Сразу определимся, я не против XSLT и даже активно использую, но не для всей страницы целиком. Главная проблема это собрать полный документ со всей инфой, встречаемой на странице. Элементарно представь статью, справа новости/анонсы, менюшки и прочее, всё это не зашито, а добавляется по мере жизни проекта.

Тут два пути, либо собирать страницу из кучи XML ресуросв (document()), но тогда вся система должна быть просто идеально спроектирована по вебсервисам (требуется работа мастера, редко встретишь). Некоторые сложности будут во взаимодействии между сервисами, например у меня (ещё не готово) меню строиться "компонентом движка", к которому любой другой может обратиться и сказать что сейчас показываем (формально идентификатор ресурса + параметры). Менюшка подсвечивает опции + эта же меню с другого view рисует хлебные крошки. Это всё в одном запросе, т.е. быстро и просто. Теперь представь как ты реализуешь "хлебные крошки" имея туеву хучу разрозненных сервисов? Оцениваем все сложности 

Второй путь это строить "обычный движок", где каждый копонент "рисует" в XML канву. Тогда документ представляет из себя массу контейнеров с аннотациами. XSLT стили получаются сложными, потому как в обрабатываемом документе может встретиться всё что угодно. Главное это ограниченность общего контейнера/документа, ведь если продумаешь всё до деталей, то XML получиться через чур сложным (не меряное количество "мета инфы"). Таже новый компонент как то должен публиковать свои XSLT стили, согласовывать их со всеми остальными. Т.е. всё упирается в реально прямые руки программиста/проектировщика.

А теперь задумались будет ли легче писать новый компонент к такому движку? А что конкретно полезного несёт "фанатичное использование XML"? А что реально полезного? А кто реально писал компонент под такую систему, доставал из канвы нужный контейнер, собирал DOM'ом поддерево? Матерился когда дескриптивные возможности документа оказывались ограниченными, а менять схему нельзя под страхом смерти? А кто переписывал десяток компонент после очередного изменения схемы документа, ибо "чистым DOM'ом собирали"? А кто пил капли когда писал XSLT под этот "через чур гибкий" документ? А оно вам надо? 

ИМХО вывод: используйте инструменты там, где они дают вам преимущество. Пишите раппорт в XML, потому что схема точно известна, трансформацией в XSL-FO -> (PDF/ODF/.rtf/.doc) легко получить что требуется. Не пишите веб страницу целиком в едином XML. Иногда шаблонизатор проще, зачем делать зря жизнь сложней? Аргументы против? 

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

К примеру сейчас преписываю шаблонизатор (черновик, в конце бред), этакий merge языкового пакета (gettext like + форматтеры из моего другого поделия) и шаблонизатора. В идеале код не должен содержать текста вообще, всё обслуживается view объектом, который пользует интернациональный шаблон.