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

CMS. Тесная интеграция с AJAX. Заодно модель рендеринга страницы.

Rammstein

PHPClub::News
CMS. Тесная интеграция с AJAX. Заодно модель рендеринга страницы.

Делаю CMS. Хотелось бы, чтобы AJAX поддерживался в ней самой. Сам незнаю даже с какой стороны к этой проблеме подступиться.
Но AJAX без всяких сомнений нужен. Но не для повсеместного использования (AJAX driven).

Схема обработки запроса (если кто-нибудь поймёт чего; 91,5Kb):
http://gm.rikt.ru/cms_request_process.jpg

Очень грубая схема рендеринга страницы:
http://gm.rikt.ru/cms.gif

Теперь словами то что на схемах. Всё в схемах отталкивается от понятия "страница". Каждая страница - есть самый верхний блок. Блок - это часть страницы, генерируемая модулем из шаблона, данных и настроек, при этом, в блоке идёт управление кэшированием всего этого. На странице есть главный модуль, который диктует настройки страницы (например, устанавливает заголовок). Модуль может иметь под-модули. Т.е. там может до бесконечности вложенность быть. Для простоты, в любом шаблоне (ака представлении), будь то шаблон страницы или модуля (что есть почти одно и то же) под-блоки вставляются через
PHP: 
<?$this->insertModule($name)?>
Вот так, вобщем. Скорее всего из этой цепочки выкину VFS_Object, или оставлю лишь для того, чтобы получать имя модуля, а уж модуль будет решать - идти путём создания страницы и её рендеринга или вывод инфы на своё усмотрение. Например, это для SOAP... и AJAX нужно.

У меня почему-то интеграция с AJAX именно здесь видится. Странно :-/
 
svetasmirnova

svetasmirnova

маленький монстрик
А чем CMS, интегрированная с AJAX отличается от CMS, не интегрированной с AJAX?
 

Rammstein

PHPClub::News
Проблема в том, что я не представляю как AJAX должен быть завязан с CMS. Возможно, нужно будет создавать отдельные модули, которые будут общаться с AJAX. Опять же, как они это будут делать? Ладно, допустим через уже ныне существующие библиотеки. Но первая проблема всё ещё остаётся.

P.S> На сколько будет удобна такая система рендеринга? Я ещё не придумал задачу, с которой она бы не справилась (SOAP, AJAX не считается)

Tor
Надо было предложение до конца прочитать :)
В данном случае "часть страницы" - ни что иное, как кусок (x)HTML

svetasmirnova
Наверное, удобством внедрения AJAX. А точнее, скоростью.

master_x
Возможно.
 
svetasmirnova

svetasmirnova

маленький монстрик
>удобством внедрения AJAX. А точнее, скоростью.
А как это: внедрять AJAX? Скоростью чего? Обмена данными по протоколу http или внедрения?
Проблема в том, что я не представляю как AJAX должен быть завязан с CMS. Возможно, нужно будет создавать отдельные модули, которые будут общаться с AJAX. Опять же, как они это будут делать?
Нажмите для раскрытия...
А ты писал маленький тестовый скрипт, который общается с AJAX?
 

Rammstein

PHPClub::News
svetasmirnova
> А как это: внедрять AJAX? Скоростью чего? Обмена данными по протоколу http или внедрения?
Нет, скоростью добавления самой технологии в том или ином виде на сайт. Иными словами, количество затрачиваемых человекочасов/минут.
> А ты писал маленький тестовый скрипт, который общается с AJAX?
Ма-а-аленький? Да. Толку с него мало.
 
svetasmirnova

svetasmirnova

маленький монстрик
Нет, я правда не понимаю, чем внедрённый AJAX от невнедрённого отличается.
 
vitus

vitus

мимо проходил
я чота не понял - что такое блок и что такое модуль, точнее разницы не уловил.
что такое VFSObject ?

а для поддержки AJAX имхо лучше иметь отдельный MainController
 

Rammstein

PHPClub::News
vitus
В блоке происходит, в основном, кэширование результата обработки модулем шаблона, данных и настроек. Так же в блоке происходит инициализация модуля. Т.е. если заранее заданы в БД все настройки, то блок вытаскивает их оттуда и добавляет в модуль.
Фактически, блок - это настроенный под конкретное место модуль + кэширование.

С отдельным MainController'ом идея интересная. Но как определить какой контроллер использовать?

svetasmirnova
Скоростью выполнения задачи, поставленной перед разработчиком. Чтобы не приходилось каждый раз изобретать велосипед.

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

-~{}~ 31.03.06 21:20:

vitus
VFSObject - объект на который направлен запрос. Он находится в VFS (читай последний PHPInside).
 
vitus

vitus

мимо проходил
тоесть блок - это контроллер, и эти контроллеры собраны в дерево?
а модуль - это типа модель (или фасад к модели)?

тогда непонятно - что такое Page :)

Но как определить какой контроллер использовать?
Нажмите для раскрытия...
апач определит по пути :) но можно и в VFS определить.
 

Rammstein

PHPClub::News
Page - тот же блок, только с дополнительными наворотами, вроде методов: addJS($file) или addMeta($name, $value)
Мне явно не подойдёт выделять в отдельный URI запросы. У меня делается так:
Если uri /some/path/ , то в дереве есть узел /some/path/ , в котором прописан объект (тот который VFSObject), а далее на схеме отображено. Но я ещё подумаю...
 
vitus

vitus

мимо проходил
1 VFSObject может иметь тип?
2 блок может иметь тип?
3 я правильно угадал про контроллеры?

Кстати StandartBlok - это класс или интерфейс?
 

Rammstein

PHPClub::News
1 Да
2 Скорее нет. Все данные они получают из БД, а реализация одна и та же.
3 Да, похоже на то.
StandartBlock - пример стандартного поведения блока.
 
vitus

vitus

мимо проходил
для всех, кто озабочен cms или framework :)
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
 
_CMD_

_CMD_

Новичок
Вы бы лучше чем наежать показали бы где человек неправ...
А не прав он прежде всего в понятие самой технологии AJAX.
SOA и AJAX это разные технологии впринципе. AJAX предназначен для создание аналога толстоклинтных приложений в WEBе. дополнительные приимущества это уменьшение нагрузки на сервер и уменьшение трафика, но значительно увиличеваются накладные расходы процессора и памяти на клиенте.
Что касается смысла делать CMS с поддержкой AJAX и SOAP, то это имеет смысл поскольку постольку рынок данных решений еще пуст, а к Web 2.0 переходить все равно придется иначе, сайты WEB 1.0 буду иметь меньшую привлекательность. НО, есть масса ресурсов в которых не нужно использовать Rich технологии. AJAX требуется там где нужна действительно итерактивность, приведениея интерфейса к виду GUI Винды...

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

Sherman

Mephi
До реального GUI, AJAX далеко, как нам до Плутона.

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