Я очень рад, что сегодня появилось немного времени и получилось сделать чтото вроде Kick Off - шаблона.
Конечно, это пока необтёсанное брёвнышко, но уже (хоть и минимальная, но всё же) CMS на XML.
(я знаю, что там можно многое улучшить, но к сож. время кончилось у меня на сегодня)


Сделал макет, куда можно добавлять свои модули. Если понравится, давайте возмём за базу для разработки, чтобы было уже на чём строить.
Просто распакуйте папку в PATH_TO_APACHE/htdocs и запустите localhost/cms в браузере.

Нравиться, что получилось сравнительно просто.
в папке src/modul 2 модуля. Один - зачаток фотоальбома, другой дамми для тестов. 

Итак - вперёд!

Вчера по запарке залил версию без стилей. В этой и стили и пример локализации есть

Присоединённый файл ( Кол-во скачиваний: 27 )
 cms.zip 459,25 Kb

Тварищи, нужны комменты!

Добавлено @ 12:53 
Я ориентировался на CMS PHP-Nuke, который использовал в этом проекте
http://www.standards-forum.de/

ПО большому счёту с другими CMS не работал и не знаю, что там ещё всё надо.

Гм .... Вот что я увидел:



У меня Денвер.

Добавлено @ 13:57 
Ребята, сорри ... Туплю ... PHP5 то я забыл установить ...   

Ну, без обьектов мы никак  Решили же на них делать. 

ПС:
Вывод ХМЛ пока просто сделал через шаблон, так как интернет дома никакой и с ДОМом я так быстро не разберусь. Но там всё так постарался сделать, что будет легко переделать на ДОМ. Кто сможет, сделайте пожалуйста. И ещё.. репозиторий у нас есть уже?

я обязательно вскоре протестирую. Очень интересно.

Демка (online)
Архивчик ещё раз

sergej.z, 
Загляни в тему "стардарты кодинга". А то хер че поймешь)

Тебя тоже не поймёсь. Что ты хочешь этим сказать? Какое это отношение к шаблону имеет?

sergej.z, взглянул на XSLT и страшно стало. Как то я совсем далек от этого ...   

skalex, а ты не смотри!  Сам модуль пишется намного проще:

Модул состоит:
ХСЛ - шаблон (все необходимые переменные появляются с инклудом core.xsl)
Пхп - генератор (то есть генератор ХМЛ)

Вот ХСЛ (пишешь на самом деле только между <xsl:template name="startmodule"></xsl:template>)


И такой ХМЛ надо будет генерить от руки:


Вот и все пироги  

ПС:
А ну да, ещё файлик с переводами туда 

sergej.z, в начале не понял, в чем дело, потом вспомнил, что PHP5.1 понимает по-умолчанию только если ПХП-код начинается с <?php

Простого <? недостаточно. Скрипт у меня выводил:


поэтому на будущее предлагаю всем на всякий случай писать везде <?php

В php.ini за это отвечает директива:

Хорошо, не проблема. Домой приду, посмотрю, что там в репозитории. Чтобы через него работать.

Добавлено @ 18:47 
И словарик надо будет на XInclude переделать. Тогда наверное и под 9 оперой пойдёт 

Ребята, мне понравилось ядро предложенное Сергеем. Предлагаю всем ознакомиться и если возражений нет, то именно на этом продолжать дальше стоить CMS. Я считаю, что это подходит полностью.

Поддерживаю!

Да спасёт тебя Великий Ctrl+Shift+F в Зенде 

Сергей.

Основным недостатком данного подхода считаю блочность. Ты базировался на PHP-Nuke? Да, он болеет этим, и это плохо. addRightGroup -- скажи, а если колонок не две, а три? А если на главной странице 4 колонки, а внутри 2? А если контентный блок есть ещё в шапке (а он обычно есть -- хотя бы баннер)? То есть на уровне движка рулить "лево-право" считаю неправильным. Далжен быть просто addGroup, а рулиться эти группы должны в шаблонах (core.xslt or smth.) Потому что поменять местами право и лево -- это, согласись, дизайн, а не логика. А дизайн должен быть в шаблонах, чтобы потом не пришлось гоняться по всем кодам и менять право с левом.

Потом. Всегда считал неверным пляску от action'a. Я придерживаюсь подхода, при котором сначала загружается базовый шаблон, а потом уже он определяет, что делать дальше (обычно у меня он делает просто <xsl:apply-templates /> -- это аналог твоего поведения, но у меня это лечится, а у тебя нет). И нет такого понятия, как "xslt текущей страницы" или т. п. А у тебя есть шаблон, который зависит от текущего экшена. Честно, не скажу, почему твой подход мне не нравится. Чисто интуитивно -- теряется универсальность. Но сидел думал час, так и не смог придумать примера -- всё же обычно основной контентный блок ровно один, а остальное замечательно вписывается в core.xslt. Придумаю -- скажу 

P. S.
В concat(concat( , вроде, нет необходимости -- эта ф-ция понимает сколько угодно параметров? 

dm9, дельные вещи говоришь.

И с чего вы взяли, что этото пример определяет поведение будующей CMS? Я слепил пару блоков для наглядности, чтобы показать как их можно будет подгружать и отображать в XML/XSL, а совсем не собирался направление задавать. Про сам движёк ПХП я даже не думал.
Ещё раз 
Пример показывает, как можно осуществить модульность + локализацию на XML/XSL (с того топика и ссылается), а совсем не диктует, где что будет находиться и как грузятся модули (тем более, что они автоматом из БД должны грузится в зависимости от настроек.)


Универсальность не теряется, наоборот повышается модульность. Написал ПХП генерящий ХМЛ + ХСЛ шаблон для него. Вот и готовый модуль.


Разве concat не 2 параметра понимает? В С, ПХП, Мускул это вроде та.

Добавлено @ 14:53 
Гы  Это конечно прикольно было бы получить готовое ядро CMS из 100 строк. Нет уж  Основная работа впереди.


От чего нибудь всегда надо плясать. Универсально "для всего" один шаблон написать не получится, сколькими ты его функциями не пичкай. 

Универсальность хороша там, где не важны конкретные особенности. И универсальность всегда обратно пропорциональна скорости выполнения и времени написания. Чем конкретнее модуль, тем лучше его и делать конкретнее.

Почитал про concat. Действительно, удобно. Надо будет переделать.



В принципе я так и думал группам просто имена давать, а в шаблоне разбираться, куда с каким именем лепить. Но это просто надстройка над тем ядром, которое я написал. Просто на бесконечном уровне абстракции надо намного больше времени для работающего варианта.

Гы! Я понял, почему неразберишка вышла. Из за того, что я назвал группы left и right. Господи, да замените лево/право не синее/зелёное, или 1/2. Естественно, что в конечном итоге XSL решит куда, какую поставить и лево направо поставит, если юзер захочет. А пример на то он и пример, чтобы понятным быть.


Проблема подхода apply-templates в том, что уже ХМЛ в этом случае орпеделяет структуру выхода. Это не всегда надо. Не получится все элементы назвать по-разному, чотбы не дублировать инфу. А если у тебя дав одинакого названных элемента с разным содержанием, то придётся в  apply-templates передавать параметр, определяющий. Так какая разница получается тогда в apply-templates и call-template?

Мой подход больше похож на вызов функции. Какую надо, ту и вызываем. Да, теряется универсальность при которой бросиш кусок ХМЛ и шаблон тебе его отпарсит сам, но здесь встаёт то факт, что ХМЛ определяет положение элементов, а я хочу, чтобы это делал исключительно шаблон. 

Я тоже за call-templates. Однако мне кажется что AddGroup это не совсем то что нужно. Есть определенный набор шаблонов который определяет основной вид страницы и ее блоки, между тем модули генерируют XML и уже на выходе определяют какие шаблоны должны рулить содержимым и какие блоки должны присутствовать.

Повторяю, AddGroup просто добавляет группу в CMS. Где она будет оторбражена (и будет ли отображена вообще) всё ещё решает шаблон естественно. Он может решать это в зависимости от ХМЛ. Это уже по вкусу.

Добавлено @ 15:35 

sergej.z, понял))) В общем тут идет просто вызов модуля и все.

В принципе это уже все будет на уровне ядра. 
Которое, как я надеюсь, в эти выходные выложу для тестов.

Отлично! Хорошие новости!

Раз это так здорово, я там два маленьких файлика кинул для затравки.
Это что-то вроде примера интерфейсности и абстрактности системных классов.

Тут кстати проблема с подгрузкой неопределённых ХСЛ шаблонов. А именно: Нельзя в коде ХСЛ подгрузить шаблон, определённый в ХМЛ или где нибудь ещё. Если бы это было возможным, многое стало бы легче. 
пример: <xsl:include src="$какая_то_переменная.xsl"> нельзя!
Я неsсколько недель над этим бился. ХСЛТ такого на позволяет. Единственно, где можно динамически определить имя шблона - в генерируемом ХМЛ . Один раз при загрузке. Поэтому я сделал подгрузку ХСЛ модуля в первую очередь, а он уже тянет вполне определённые ХСЛ (core, header, footer)

Добавлено @ 17:45 

Как только появится возможность, посмотрю (где то послезавтра вечером)

sergej.z, а что мешает делать import в шаблоне? 
К примеру включаемый XSLT шаблон имеет имя вроде
file-003154.41.5151.5615.1.xsl
При запросе пользователем там компануется XSLT шаблон на сервере, я так сам делал.

http://sergejzr.jino-net.ru/vcms/ мёртв 

Добавлено @ 23:39 
Оп, прошу прощения, не мёртв! Но хочу обратить внимание что в Опере ничета не работает

smartov, опера тихонько курит в сторонке.

Компановать ХСЛ динамически конечно можно. Только с кэшированием надо всё правильно определить. В принципе неплохое решение. Хотя конечно с ХСЛ файлами было бы элегантнее, но если нам возможность не дают (кстати, кто нить знарт, почему?)...

sergejzr, не, не в курсе почему нельзя на лету их подключать...

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

Вчера попробовал... Вопрос такой: Если шаблоны генерить, как будет работать серверное преобразование?
Вчера я искал решение этому, но никак не нашёл. Пока остаётся только предложение опере серверное преобразование делать, а все шаблоны печатать одинаковыми.

Вообще у нас всего в одном месте генерить надо было бы. Там, где различается поведение браузеров.

sergejzr, ага. А в чем собственно вопрос по преобразованию? Я проблемы не вижу.

Ну если хсл генерится динамически, то это ведь пхп-файл. Для того чтобы получить ХСЛ, надо его отработать. 
Например пишу:


<xsl:import src="xy.php">

Браузер всё правильно сделает, ведь он будет запрашивать xy.php у сервера и получит правильный стрим.
А что будет делать преобразование на сервере? Ведь для него xy.php так и останется файлом пхп.

(Сорри, если туплю. С сервеным преобразованием пока не работал.)

Значит так, если мы даем клиенту XSL шаблоны, вставляем ипорты DOM'ом в уже готовый основной шаблон, ну или тот который назначен основным для запрашиваемого документа. В XML вставляется ссылка типа http://www.example.com/xslt-gen/pageid-13143452.xsl. В скрипте, который отрабатывает при этом запросе, достаются все шаблоны привязанные к документу 13143452 и собираются в основном шаблоне.

Если на сервере, то в самом ядре происходит сборка шаблона (вставка импортов), потом преобразование.

Вроде собственно и все.

Понятно. Чтож как выход для оперы - вполне нормально.

Как насчет ядра? Сможешь в эти выходные заняться?

Вов, читай ниже, я уже писал что постараюсь выложить бета версию ядра в эти выходные)))

IZ@TOP, я читал. Поэтому и спросил, не поменялись ли планы.

Wowa, тогда ясно. С планами вроде как определился, так что все нормально.

IZ@TOP, есть какие-нибудь новости?

IZ@TOP, ну как там?

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

Но дело идет по тихоньку. Смотрите каждый вечер обновления.

Какие сейчас актуальные проблемы и задачи?

Я прошу всех разработчиков ознакомиться с ядром системы на SVN и задавать свои вопросы. (один вопрос - одна тема). Иначе потом будет поздно.

Добавлено @ 16:09 
Wowa, насколько сейчас взаимосвязь твоего кода с кодом Сергея?

Подключаюсь, возможно, поздно. 
Предлогаю еще сделать, если есть блок, к примеру, с последними новостями или последними сообщениями в форуме, то нужно типа <xsl:call-module name=News row=10> ну или что-то в таком духе. Удобно.

Хотелось бы примкнуть к команде.

Вопрос по модулям:



а если 20, 30 модулей? Это каждый так надо будет добавлять?
Предлогаю так:
Сначала смотреть какие модули в шаблоне, далее уже в цикле проганять кусок:



Ну что-то в таком духе. Пока еще не во всем коде разобрался. Времени не очень много.

Оффтоп: мне кажется или я и вправду поздно подключился. Все утухло, что ли? ((

Не поздно. Просто пока, как видишь, затишье. У меня лично это связано с временным отсутствием инета. 


Естественно нет. Названия подключаемых модулей, их позиция итд. беруться из БД. Потом подгрузка непосредственно модулей (их ХМЛ)


Шаблон не определяет, какие именно модули. А то придётся его перекраивать при каждом изменении. Как я уже писал, это делает БД.

Ок, ясно 
Я так и хотел предложить.

Добавлено @ 14:08 
А как мне вообще принять участие в разработке? Если, конечно, команда не против.

Настрой доступ на SVN, загрузи исходники того, что мы уже написали. Ознакомься с ними и предложи то, что ты хотел бы делать.

>>Настрой доступ на SVN, загрузи исходники того, что мы уже написали. Ознакомься с ними и предложи то, что ты хотел бы делать. 

С SVN все слил, ознакомился. Думаю, хотел бы, заниматься какими либо модулями. В api многое понравилось, так что туда не буду лезть ))

Semenov, там сейчас вроде как два API. Одно мое - другое Сергея. 
Они в общем похожи, по идеологии, но есть отличия в архитектуре.

Я смотрел Сергея. Сейчас посмотрю твое )