Xpoint
   [напомнить пароль]

Cтруктура CMF

Метки: проектирование, разработка, cmf
2005-07-25 02:29:32 [обр] sharf[досье]
Решил писать свою CMF. Перед тем как писать код, нужно четко представлять архитектуру всей системы. Вот что у меня получилось:
http://copi.ru/50982/my/files/get/?fname=cmf.gif
Какие у кого идеи и предложения?
спустя 10 часов [обр] 30-ый(0/584)[досье]
Идея 1. Не заниматься изобретением велосипеда, а взглянуть на то что уже есть. Лучше вы наврядли напишите, а вот хуже почти наверняка.
Идея 2. Современная CMS должна базироваться на XML/XSLT.
Идея 3. Структура с 10 квадратиками не может сколько нибуть понятно описать CMF.
Идея 4. Было бы неплохо также определить средство разработки и поддерживаемые БД. По расширению центрального файла могу предположить, что это PHP. Отсюда:
Идея 5. Писать на PHP подобные системы это самоубйиство. В отсутсвии нормальной поддержки типизации, внутрисерверных редиректов, фильтров и еще сотни нужных для таких проектов вещей, у вас намотаются рельса на колеса значительно быстрее, чем будет готова бета-версия.
спустя 1 час 30 минут [обр] Thirteensmay(0/157)[досье]
Для начала неплохо определиться для чего она Вам нужна. Будет ли она "концептуальной"
или реальной. Смешно смотреть на потуги многих современных разработчиков наворачивающих свои
системы до безобразия. Приведенная Вами структура наиболее типична для таких вещей.
А вот конечная реализация... Интересно, куда Вы собираетесь привязать "?" ?
спустя 15 минут [обр] sharf[досье]
Thirteensmay писал: Будет ли она "концептуальной" или реальной.
Отвечаю: система нужна для содания реальных проектов, хотя сама по себе она должна оставаться независимой и абстрактной, с воможностью развития и редактирования.
Куда привязать "?" хотел как раз спросить! Поэтому собственно и поставил "?". А как еще можно представить структуру CMF?
спустя 12 минут [обр] Thirteensmay(0/157)[досье]
Ну для начала: Где у Вас в системе будет динамика ? В *.Inc или там только статика ? (судя по комментарию)
спустя 33 минуты [обр] sharf[досье]
Объясню подробнее как будет работать моя система:
-config содержит базовые настройки конкретного проекта: пути, тип БД и т.д.
-ядро поключает config и модуль БД, для конкретной БД, определенной в config
-ядро содержит функцию подключения модулей load_mod(имя_модуля) и остальные служебные функции
-БД содержит талицу с id и свойствами всех страниц: тип страницы, список подключаемых модулей и другие
В итоге index.php подключает
-ядро
-БД
-получает тип, свойства, список подключаемых модуей из БД
-подключение модулей
-подкючение кода страницы
-получение контента
-вывод страницы
спустя 4 минуты [обр] sharf[досье]
Thirteensmay писал: Где у Вас в системе будет динамика ? В *.Inc или там только статика ?
В inc находятся только постоянные фрагменты HTML-кода. А динамика в модулях и в коде в зависимости от типа страницы.
спустя 30 минут [обр] Thirteensmay(0/157)[досье]
Т.е. все запросы обслуживает index.php ? далее уточните что есть "модуль", "подключение модулей",
"подкючение кода страницы" и "получение контента", как это происходит ? Если возможно то на
примере простого реального запроса, допустим менеджеру требуется список адресов партнеров (который лежит в базе), как в этом случае будет сформирован конечный ответ системы ?
спустя 21 минуту [обр] sharf[досье]

модуль
 -класс на PHP, т.е. набор функций+внутренняя информация:версия, параметры и т.п.
подключение модулей
 -происходит в index.php функцией ядра load_mod(имя_модуля), т.е. практически require("путь_к_файлу_модуля") или include(), список модулей для каждой страницы свой и определяется базой;

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

спустя 2 часа 59 минут [обр] Thirteensmay(0/157)[досье]
т.е. имеем запросы вида: index.php?page=page_id, далее ядро по page_id определяет и подключает
модули, что из них выполнять ? это будет определено какойто семантикой или просто выполняется
функция по умолчанию/весь модуль ?
спустя 36 минут [обр] sharf[досье]
подключается весь модуль, а вот какие функции выполняются определяется типом страницы. Т.е. модуль news (новости) может вывести как отдельную новость, так и весь список новостей! Но получается что тогда должны существовать заранее определенные типы страниц... вот как раз и отступление от абстрактности системы! Как лучше реализовать такую идею? Может пускай модуль определяет тип допустимых страниц? Но как собрать все типы вместе, чтобы заранее знать какие из них можно использовать? Может подкините каких-нибудь идей?
спустя 2 часа 23 минуты [обр] Thirteensmay(0/157)[досье]

Во-во, получается что система должна сама знать как работать ;) Даже мы далеко не так
совершенны. Именно это я и имел ввиду когда спрашивал не будет ли она у Вас "концептуальной".
Конечно, большинство вопросов такого плана можно решить если строить законченную систему - читай
конкретное приложение, но не в данном случае. Можно даже найти какието более менее универсальные
подходы, но со временем они будут разрастаться и приведут к конкретной каше. Microsoft тому
ярчайший пример. Выход ? - не стоит считать себя богом и сильно заморачиваться. Делайте проще,
и получите как следствие гибкость. Вот гибкость + простота и есть удобство !, а вовсе не
заветный "один клик", еще раз повторюсь: "Для начала неплохо определиться для чего она Вам
нужна ?" Так вот блин, для чего нам CMF ? - для упрощения своей жизни, чтобы быстро состряпать
что угодно, но не запутаться потом в этом а эффективно управлять. Реальный выход ? - делайте
маленькие независимые (как они будут "думать") модули и управляйте ими (нет аналогий ;) ?),
также определите "общие соглашения" ;). Естественно это не отменяет качественного
программирования, однако позволяет избежать бардака, и выстроить четкую логику.
Где же место CMF ? - это просто интерфейс управления всей этой лабудой. А на основе чего ?
- на основе предоставляемых ею функций, как админу так и нашим "независимым модулям".
Впрочем, модули и вправду независимые - не хочешь пользоваться "интерфейсными функциями" ;) -
не пользуйся, модуль мал - его просто того, , заменить... ;) Все еще не находите аналогии ?,
а она между тем ужасна ;). Технический выход ? - абстрагируйтесь на уровне скриптов. Конечно,
можно и с данными побаловаться, вот только сдается мне что такое баловство в случае с CMF,
не что иное как изобретение капкана себе любимому. И управляйте ими, предосталяйте им
"интерфейсные функции" и пр... У меня так: база скриптов, база пользователей, база настроек,
единый интерфейс БД, функции идентификации, организации сессий, распределения доступа,
визуализации и пр. + библиотека универсальных функций упрощающих жизнь (I/O, проверки,
сортировки, отрисовки и т.д.). Естественно это все более мене взаимосвязано, остальное извиняйте
- ручками. Дешево и сердито, а также просто, удобно и достаточно быстро если чего приспичит,
а еще, когда это случается, я знаю что и где глючит. Какой нахрен XML и иже с ним ! ;)

p.s. ну вот, а хотел новую сортировку испытать седня...

спустя 15 часов [обр] sharf[досье]
Убедительно сказано! Спасибо! Полностью согласен насчет простоты и "остальное извиняйте - ручками". Так вот в этом и проблема... хотя скорей не проблема, а задача: как организовать простую CMF, чтобы такие важные части как ядро оставались постоянными, а улучшения и добавления безболезнено встраивались в нее? Вопрос конечно не имеет четкого ответа, просто хотелось бы знать мнение по поводу моей схемы и послушать как еще можно ее представить!
спустя 13 минут [обр] 30-ый(0/584)[досье]
как организовать простую CMF, чтобы такие важные части как ядро оставались постоянными, а улучшения и добавления безболезнено встраивались в нее
Как найдете решение, не стесняйтесь, подавайте на нобелевскую премию мира :-)
спустя 26 минут [обр] sharf[досье]
Rodion Alukhanov: спасибо за совет! обязательно воспользусь! хотя лучше бы кто-нибудь покинул какую-нибудь идею!
спустя 29 минут [обр] 30-ый(0/584)[досье]

Да нет тут идей. Вы задаете слишком глобальные вопросы, предоставив слишком мало информации. Вы должны сначала для себя понять как будет работать эта система, и как уже заметил Thirteensmay[досье], для чего она вам собственно нужна.

Вы хотите сделать что-то универсальное? Попробуйте написать это текстом. Если у вас получится меньше 30 листов, то значит вы еще сами не поняли, как все это будет работать.

Кстати, повторюсь. Ничего универсального и идеального в современном мире не будет популярным и полезным без XSLT шаблонов. Если вы не знаете как грамотно работать с XML, можете смело отложить наполеоновские планы и отправить себя в книжный.

спустя 18 минут [обр] sharf[досье]
Rodion Alukhanov: Спасибо за совет! Обязательно воспользуюсь!
Кстати вот еще задумался по поводу прав доступа в предложенной мной схеме. Думаю вот что:
-Можно либо ограничивать доступ ко всей странице, т.е. у каждой страницы есть свой барьер для польователей
-Либо взять функцию проверки прав и вызывать ее в начале каждой функции модуля, т.е. пользователь может и увидит форму добавления новости, но вот добавить то и не сможет! как раз и получается предложенная Thirteensmay схема право-скрипт.
спустя 27 минут [обр] Thirteensmay(0/157)[досье]

To sharf: не стоит так доступом рулить ("т.е. пользователь может и увидит форму добавления
новости, но вот добавить то и не сможет!") - Представьте себе: сели Вы набрали 30 страниц текста в
Worde, а сохранить то их он Вам и не дает ! ;) Лучше сразу пинка давать - выдавать сообщение что
досуп закрыт когда пользователь хочет обратиться (в моем случае к закрытому для него скрипту).
А в идеале - так и ссылок давать на закрытые ресурсы ненадо, а если нагло лезет - пинать.

To Rodion Alukhanov: Ну может Вы мне наконец таки нормально объясните в чем необходимость XML ?
А то сколько с народом не разговариваю, немогу понять его реальной пользы ?, ну кроме призрачных
перспектив в будущем...

спустя 42 минуты [обр] 30-ый(0/584)[досье]
Сам по себе XML не так уж интересен. Я говорю про шаблоны XSLT. Они позволяют делать в общем то как раз то, что каждый "разработчик универсальной CMS" изобретает каждый раз по новому. XSLT же предлагает:
- бесплатную,
- стандартную (доступную в почти любом языке программирования),
- популярную (читая менее глючную),
- целостную (без корявых подпорок и заглушек),
- очень гибкую,
- документированную на любом мыслимом и немыслимом языке,
- и самое главное - УЖЕ ГОТОВУЮ
систему построения шаблонов. Время требуемое на изучение XSLT сранимо со времением изучения лобого другого языка шаблонов и уж конечно же оно несравнимо меньше, чем время разработки чего-либо подобного. При этом вряд ли вы найдете более гибкий и универсальный язык, чем XSLT!
спустя 32 минуты [обр] sharf[досье]
To Thirteensmay: когда я говорил "т.е. пользователь может и увидит форму добавления
новости, но вот добавить то и не сможет!", я имел ввиду, например, тестовый доступ или что-нибудь подобное в таком роде, а так ссылок на закрытые ресурсы я давать и не собирался... А как Вы строите сами права и их совокупности?
спустя 1 час 32 минуты [обр] Thirteensmay(0/157)[досье]
To Rodion Alukhanov: ;)
To sharf: Делаю вот как:
В БД имеем следующие таблицы: "Пользователи", "Роли", "Скрипты",
далее имеем таблицы связок: "Пользователи-Роли", "Роли-Скрипты",
данные в таблицах связок могут повторяться, например:
"Пользователи-Роли":
1 - 1
2 - 1
3 - 2
2 - 4
т.е. 2-ой пользователь может выполнять 1-ю и 4-ю роли.
"Роли-Скрипты":
1 - 21
1 - 13
1 - 76
2 - ...
т.е. для 1-ой роли доступны 21, 13, 76 скрипты.
Допустим система установила что идет обращение пользователя с userid=2,
к скрипту scriptid=13. В этом случае она проверяет доступность скрипта
scriptid=13 пользователю userid=2, предварительно формируя список его ролей:
userrules = select rule from usersrules where user=2;
select rule from rulesscripts where rule in (userrules) and scriptid=13;
если в результате второго селекта хоть что нибудь нашлось - запускаем
скрипт на исполнение, иначе редирект на "Доступ запрещен".
Внутри скрипта через интерфейсные функции доступна куча всякой инфы:
в т.ч. идентификатор текущего пользователя, такчто если кому приспичит
разруливать доступ внутри своего скрипта, (например просмотр/изменение)
- пожайлуста..., но вообще предполагается что один скрипт выполняет
одно элементарное действие.
спустя 3 часа 25 минут [обр] Thirteensmay(0/157)[досье]
Как организовать простую CMF, чтобы такие важные части как ядро оставались постоянными,
а улучшения и добавления безболезнено встраивались в нее ? ;)
Классика: Ядро отдельно - конечный функционал отдельно. Добавляйте и встраивайте
что угодно, только не мешайте этих понятий. При этом ядро реализует исключительно
базовую функциональность системы и мало.
Типично для ядра: Сборка процесса и управление его исполнением, читай подключение
модулей, функций, шаблонов ;), принятие решений о доступе, ну может быть
еще немного. Остальное - независимый функционал: в т.ч. администрирование,
интерфейс БД, визуализация и пр...
спустя 51 минуту [обр] sharf[досье]
To Thirteensmay: Спасибо за схему Пользователи-Роли-Скрипты. Только вот такая штука: каждый скрипт имеет свой scriptid, следовательно если в моем случае скрипт это функция, то она должна иметь свой уникальный номер. А каким образом в теле функции он задается? или каким образом у Вас осуществляется связь scriptid с конкретным кодом? Что Вы подразумеваете вообще под "скриптами"?
спустя 1 час 19 минут [обр] sharf[досье]

Кстати есть еще одна схема распределения прав:

00000001 - 1 - право1
00000010 - 2 - право2
00000100 - 4 - право3
00001000 - 8 - право4
00010000 - 16 - право5
01000000 - 64 - право6
10000000 - 128 - право7

Сложив любую комбинацию атрибутов, мы всегда получим уникальное число, отражающее права пользователя:

1 (00000001) - право1
49 (01100001) - право1+право5+право6
255 (11111111) - все права

Только что мне не нравится, это то, что прав всего 7, но если права заменить ролями?

спустя 3 часа 12 минут [обр] Thirteensmay(0/157)[досье]

За схему спасибо не мне а Андрею Новикову (см. предидущую тему), если он не против ;)

Под скриптами я понимаю небольшие куски кода реализующие законченную функциональность
и оформленные в виде отдельного файла, например *.bat, *.cgi, *.exe, *.pl и т.п.

Связь scriptid c конкретным кодом осуществляется по специальной таблице scripts:
(id, title, type, pathname), например: 1, 'Основная страница', local, 'pages/index.pl'

Как вы будете привязывать свои функции ? - ну например на Perl это можно сделать через eval
(генерация кода 'на лету'), а вообще чего оно вам даст ? - ну и require-те файл целиком - а в нем одна функция.

По поводу Вашей схемы распределения прав: Что значит только 7 ?, кстати - 8, ну и пользуйтесь
не байтом а обычным 32-х разрядным int-ом, будет Вам целых 32 права.
Хотя толку ? Для того чтобы упаковывать права ? т.е. не повторять записи:
  "Пользователи-Роли":
  1 - 1
  2 - 1
Ну так их же тогда упаковывать/распаковывать надо, что даст мизерный эффект в плане нагрузки
на базу/скрипт обработки, если вообще даст, но усложнит понимание.

А это на сон грядущий:
Вот реальный пример CMS написанной нами в 2000 г. на ASP под IIS 4.0 WinNT,
работает до сих пор, но код монстрообразный, жесткая заточка под 800x600,
и еще некоторые косяки, да и с Windows слазить надо, а то придут скоро...
вот переписываю...
Имеются головные скрипты вида 234.asp:
  <include header.inc>
  <include 234.inc>
  <include footer.inc>
Ессно основной функционал в 234.inc, в header.inc - ядро.
Кстати: не нравится мне Ваш подход с единым index.php?page=pageid,
впринципе ничего страшного, просто прямые ссылки вроде как логичнее.
Далее: в header.inc - идентификация на снове сессий ASP - супер, в новой пришлось
сильно извращаться, об этом позже.
Далее: проверка доступа на основе списков пользователей для каждого
скрипта - геморой, в новой не будет, см. выше.
Далее: подключение необходимых функций для скрипта, на основе опять таки списков
функций для каждого скрипта - призрачная экономия, в новой думаю выделить общие
функции (сортировки, визуализации и пр.) в отдельную библиотеку и подключать
в скриптах ручками, ессно функции ядра типа GetCurrentUserID() подключаются все,
ну так их немного, они в ядре...
Далее: подключение CSS - нормально, оставил.
Далее: Визуализация шапки, меню и пр. - строго 800x600 и так во всех конечных
скриптах - блин, ну этож надо было так прогнать... в новой все резиновое...
Далее: header.inc заканчивается, начинается непосредственно функционал 234.inc
- сделал аналогично.
Далее: footer.inc - ну тут все нормально и понятно, в основном визуализация
окончания - сделал аналогично.
В системе нет единого интерфейса БД - в новой есть, его даже ядро пользует и
распределение доступа внедрено.
Зато есть единый справочник - древовидная структура со связками: типа хеша хешей
если выражаться терминами Perl, основное назначение - глобальное обеспечение
уникальными идентификаторами и обеспечение гибкости за счет настраиваемых связей,
работает через интерфейсные функции - классно, но крыша часто едет (у меня) - упростим.
Ну и еще кучка всяких мелких сладкостей (распределение служебной БД, синхронизация
справочников разных копий системы, и пр.) + административная консоль на основе
нескольких десятков скриптов выполняющих типичные адм. функции, а также средства
удаленной разработки. - по возможности повторю наиболее полезное.
Теперь о новой:
Имеем: Perl скрипты вида:
  use Headers.pm;
  header(scriptid, type);
    print 'Вы: '.GetCurrentUserName();
  footer();
Где: Headers.pm - ядро, header() и footer() - основные системообразующие функции,
описаны в ядре. print 'Вы: '.GetCurrentUserName(); - собственно основной функционал
скрипта, в данном случае пользующий функцию ядра GetCurrentUserName().
В функции header(scriptid, type) scriptid нужен чтобы система знала какой скрипт
запускается, а type - определяет тип заголовка (с кешированием/без,
с визуализацией/без, со стандартной формой/без), о стандартной форме позже...
Чесно говоря мне не особо нравится этот "шаблон скрипта", но альтернатива ?
В Headers.pm также описаны дополнительные функции типа GetCurrentUserName().
В header() выполняется следующее:
- Идентификация (см. тему "CGI идентификация" в форуме "Технологии CGI и SSI")
основная проблема в том что для обеспечения сессий пришлось ввести функцию
для формирования ссылок. Т.к. идентификация идет на основе HTML:
т.е. система вставляет <INPUT TYPE=HIDDEN NAME='IDINFO' VALUE='XXX'> во все
свои ответы клиенту, а затем проверяет это на входе, при прямом обращении к скрипту
IDINFO не передается, и следовательно система считает что это гость, далее конечно
она формирует для него сессию и назначает NAME='IDINFO' VALUE='XXX',
если идет submit формы - все нормально - (сессия пошла), а вот прямой <a href='...'>
ее сваливает. Короче, функция ядра insertlink(URL) эмулирует <a href='...'>
через submit формы.
Теперь о стандартной форме: Как известно большинство запросов это submit-ы форм
на скрипт-обработчик. Вот я и предусмотрел вставку стандартной формы, чтобы лишний
раз не писать это в каждом скрипте, впрочем для особых случаев она может не
распространяться на весь скрипт, а заканчиваться в заголовке, т.к. по любому она
нужна для обеспечения идентификации. При этом разработчик может в скрипте
определять свои формы. Управляется це с помощью параметра type у header().
- Далее в header() будет/есть проверка доступа (см. выше), ну и еще всякие мелочи
типа проверки броузера и т.п., Все ! в header() больше ничего !, ну кроме конечно
описаний интерфейсных функций ядра. Все остальные мульки типа единого интерфейса БД,
единого справочника, системы настроек, и системы печати - отдельно.
Единый интерфейс БД например, сделал OO на основе DBI, можно прочитать в
предидущей теме этого форума, вот пример использования:
  $cnn = MyDBI->new();
  $cnn->query("select * from users");
    while($cnn->rowpresent())
    {
      print $cnn->rowfield("name"), "<br>";
    }
На текущий момент ядро приблизительно готово на 60-70% итого имеем 12Кб, думаю
уложиться в 20-30, помоему нормально ?, конечные скрипты в основном - еще меньше.
Ну помоему я Вам дал пищу для размышлений ;) да, не советую PHP, Perl - лучше ;).
Кстати, все уважаемые кто еще читает этот бред, есть ли тут у меня какие косяки ?
- не хотелось бы лет через 5 понять что система только под 800x600...

спустя 8 часов [обр] Алексей Севрюков(2/1280)[досье]

Thirteensmay[досье]

Кстати: не нравится мне Ваш подход с единым index.php?page=pageid,

Это легко решается с помощью mod_rewrite.

спустя 3 часа 1 минуту [обр] Иван Шумков(0/77)[досье]
Архитектуру CFM можно подсмотреть у товарищей с jetstyle.
спустя 28 минут [обр] Thirteensmay(0/157)[досье]
To Алексей Севрюков aka Plus: Интересно, наверное и мне тогда можно избавиться от шаблона,
т.е. не вызывать header() и footer() кадый раз. Их параметры можно перенести в базу и дергать
оттуда когда надо подключить. Вот только как ? было бы неплохо иметь "чистый" скрипт.
спустя 25 минут [обр] Алексей Севрюков(2/1280)[досье]
Thirteensmay[досье] Что-то все прямо помешались на базах. Лично мне такой подход не очень нравится. А вообще я не понял о чем Вы, что значит "чистый" скрипт в Вашем понимании?
спустя 13 минут [обр] Thirteensmay(0/157)[досье]
Алексей Севрюков[досье] А какой нравится ? ;) под "чистым" скриптом я понимаю скрипт без вызова header() и footer() желательно чтобы они вызывались самой системой, а в скрипте был исключительно код реализации его функции.
спустя 48 минут [обр] Алексей Севрюков(2/1280)[досье]
Thirteensmay[досье] Ну так сделайте ядро, которое будет это все вызывать, а в отдельных файлах размещайте только функциональный код.
спустя 1 час 11 минут [обр] 30-ый(0/584)[досье]

Неверно это делить шаблон на header и footer. Это, да простят меня присутсвующие, давно устаревший и любителский подход. Шаблон должен быть целостным и представлять собой каркас страницы. Сам же "скрипт" должен возвращать лишь отдельные данные для заполнения этого шаблона. Скрипт вообще не должен генерировать ни строчки HTML, равно как он не должен ничего слать в броузер (с помощью echo, например). Скрипт не должен вызывать шаблон, а шаблон не должен вызывать скрипт. Они оба должны просто предоставлять данные для сборщика.

Ух ты, удалось написать идею ни разу не сказав XSLT... но я надеюсь вы таки поняли о чем я :-)

спустя 56 минут [обр] Алексей Севрюков(2/1280)[досье]
30-ый[досье] И снова золотые слова. Все до единого.
спустя 3 часа 39 минут [обр] Thirteensmay(0/157)[досье]
Ну мля мужики, и что дальше ? будем прикручивать нейронные сети ? молчу... ;)
IMHO хороший подход для работы в команде, когда один рисует, другой дизайн
лепит, третий - шаблоны, четвертый - кодит, пятый - рулит и т.п.
Ну конечно это "профессионально", эффективно и бабло косить легче,
подумаешь ядро 300 Кб - мелочи по нынешним меркам, спросите у любого профи
и он вам скажет: print "Введите имя:<br><input type=text>" не в коем случае
не должен родиться вот так просто. Сначала должен запуститься линкер,
который запустит валидатор шаблонов, который запустит семантический модуль,
который запустит словарь, который не запустится а родит Исаака...
Классно, и все работой заняты... Еслибы заказчик знал за что он отдает
свои деньги он бы Вас удавил. Ругаете Била а с каждым шагом все больше
похожи на него. Так вот, а что делать если этой команды нет ?
т.е. она не может существовать по причине того что заказчик не может
позволить себе платить деньги масштаба команды. Многие в России живут.
Воровать ? Извините отвлекся, расплакался...
Впрочем автору темы на заметку: От чего может зависить структура CMF ;)
А мне может кто подскажет как сделать чтобы с одной стороны можно
было обращаться к скриптам напрямую, т.е. http://xxx/page1.cgi,
http://xxx/yyy/page2.cgi, а с другой, не писать header(); и footer();
в каждом из них, т.е. обращения должны перехватываться и перед тем
как запустить скрипт должна быть предобработка.
спустя 2 часа 1 минуту [обр] 30-ый(0/584)[досье]

Thirteensmay[досье], я вам советую таки прежде чем критиковать, купить книжку по XML. Причем не методичку подешевле, а хорошую книжку как минимум листов так на 800, а лучше на 1200. Чтобы там были изложены как минимум(!) CSS 2.1, XSLT 1.0, XPath и DTD. Причем книжку не полистать, а прочесть. Потом попробовать этим воспользовать... быть может придется себя заставить.

Раньше я был точно такого же мнения как и вы. Но попробовал и мне понравилось. Сейчас даже те проекты, которые я веду один я делаю на XSLT шаблонах. И это не потому, что я выпендриваюсь, а потому что так проще, быстрее и нагляднее.

Так вот возвращаясь к вызову скриптов. Ответ прост: Не надо к ним напрямую обращаться. Прочтите что-нибудь по Model-View-Container 2 (MVC2). Это концепция правда немного старая - написана под Java и в до-XML-ное время. Но концепция хорошая. Многие идеи прекрасно можно использовать на PHP (лично проверено). Да и автор статьи вроде что-то подобное реализует, сосредотачивая центрольное управление в едином файле index.php.

Это все конечно верно, только если мы говорим про такие умные вещи как CMF (или CMS). Можно ли программировать на PHP без всего этого барахла? До конечно можно! PHP строго говоря именно для этого и создавался, чтобы себе голову ерундой не забивать, а сразу начать программировать. Но тогда давайте не будет ставить глобальных вопросов построения универсального CMF.

спустя 4 минуты [обр] 30-ый(0/584)[досье]
"автор статьи"... разумеется имелось в виду "автор темы" :-)
спустя 10 минут [обр] 30-ый(0/584)[досье]
К сожалению, сосредоточение кода контроллера в одном одном файле не очень практично и удобно. Как с точки зрения программиста, так и с точки зрения пользователя сайта. Деление же контроллера на несколько файлов сильно усложняется отсутствием в PHP внутрисерверного редиректа и ограниченным контролем над строкой запроса... тут придется проявить фантазию. Как уже было замечено для этого в Apache есть mod_rewrite. Его многие хостеры правда недолюбливают... но идеальная CMF требует жетрв :-)
спустя 15 минут [обр] Thirteensmay(0/157)[досье]
Ну что я могу Вам ответить ;) скоро отпуск - почитаю, Вы меня заинтриговали...
А вообще хорошо подмечено в последнем абзаце Вашего поста - получается что мы говорим о разных
вещах: Вы о CMF в полном смысле этого понятия и поэтому со сборщиком ;), а я о том как с этим
особо не заморачиваясь получить несколько похожий результат на основе стандартных средств.
спустя 22 минуты [обр] Thirteensmay(0/157)[досье]
sharf[досье] А какого масштаба Ваши проекты ?
спустя 26 минут [обр] 30-ый(0/584)[досье]

Есть разные. Несколько сравнительно небольших базок на PHP таблиц эдак в 20 и порядка 600 программиро-человекочасов работы (на мой взгляд это почти максимум, что можно выжать из PHP без серьезного падения стабильности).

А есть один большой проект на EJB в 60 таблиц... надеюсь уложимся в 2500 человекочасов.

Есть и маленькие внутренние проекты на 40-80 человекочасов, где вообще только один XSLT шаблон и 10 классов Java. Но здесь XSLT тоже очень к месту, дабы во внутренних проектах постоянно что-то меняется и доделывается... часто совсем не тем, кем писалось в начале.

Эффективно ли при помощи XSLT делать какие-нибудь стандартные статические сайты с 2 формами отправки почты и прайсом?... не могу с уверенностью утверждать. Возможно дополнительные расходы на более изысканный хостинг и админов к нему не окупят затею с XML. Равно как часто не имеет смысла делать такие проекты Java.

Вот сравнительно неплохая книжка:
XML Bible (перевод на русский есть). Достаточно подробно и при этом без воды. Там к сожалению не описаны интерфейсы доступа к XML из программ, т.е. интерейсы DOM и SAX (они немного специфичны в разных реализациях), но сам XML охвачен широко и сравнительно глубоко (на сколько это вообще возможно на 1200 страницах).

спустя 1 час 5 минут [обр] Thirteensmay(0/157)[досье]
30-ый[досье] Просто я отталкиваюсь от следующих соображений:
каждый программист хвалит то с чем работает в большой степени потому что он к этому ПРИВЫК,
а также то что обычно при смешивании получается каша. Раз уж мы тут такую простыню накатали,
может быть не сочтете за большой труд привести реальный пример выгоды от использования XML/XSLT ?
Ну нехотелось бы выкинуть деньги на приобретение очередной макулатуры ;)
Просто я подозреваю что все что там есть, можно сделать используя классические подходы
особо ни в чем не теряя...
спустя 9 часов [обр] 30-ый(0/584)[досье]

<RTFM>

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

Пример 2 (немного отвлеченный):
Тот же самый XML можно передать на обработку GUI-приложению. Учитывая, что распарсить XML не сложнее чем сериализованный объект, мы имеем лишь один бизнес-метод для любого предстваления (GUI, Web, SOAP)

Пример 3:
Задача обратная первой. Есть уже готовая страница (шаблон) и в нее надо вставить некие кусочки работы скрипта. В этом случае в страницу вставляются некие маркеры, а скрипт генерирует XSLT с кусками XHTML кода для замены этих маркеров. Это в разы(!) гибще, чем принятые у многих программистом маркеры типа "###USERNAME###". Дабы мы всегда можем сравнительно бескровно модернизировать маркеры и сделать что-то типа

<marker field="username" show="FULLNAME" show-when-null="false"/>

в классических самопальных шаблонах пришлось бы либо придумывать новые маркеры, либо самому парсить текстовые строки. Я уж не говорю про то, что распарсить шаблон на XSLT быстрее чем ручками, дабы парсеры XSLT вылизывались и оптимизировались годами.

</RTFM>

Можно ли все это сделать без XML? На кто бы спорил, конечно можно! Некоторые до сих пор пишут программы исключительно в Notepad'e и категорически не признают подсветку синтакиса. Причем программы от этого получаются совсем не хуже. Каждый выбирает свой метод. А за макулатуру не беспокойтесь, как минимум в резюме напишите XML/XSLT. Это ж ваще читста круто :-)

спустя 48 минут [обр] Thirteensmay(0/157)[досье]

30-ый[досье] Спасибо ;), ну есть конечно варианты...

Я так думаю можно подвести некоторые итоги:
Уважаемые товарищи разработчики собственных CMF, определитесь для начала для чего
она Вам нужна, прикиньте масштабы и сопоставте собственные силы,
ибо в общем случае есть 2 варианта: полные и облегченные версии.
В случае полной версии абсолютно согласен с 30-ый[досье]:
"Не заниматься изобретением велосипеда, а взглянуть на то что уже есть. Лучше вы наврядли напишите, а вот хуже почти наверняка.", тяжелая это вещь, намучаетесь...
Впрочем ссылки и основные идеи здесь и в форуме приведены...
В случае облегченной версии, вполне реально осилить разработку самому и получать на выходе
достаточно простые и оптимизированные решения, вполне возможно с использованием XML/XSLT,
не так глобально конечно, но в большинстве случаев хватает. Я тоже коекакие идеи привел,
берите с поправкой на XML...

спустя 10 часов [обр] sharf[досье]
Спасибо:) всем! Теперь у меня действительно предостаточно тем для размышления!
спустя 6 дней [обр] Алексей Степанов[досье]
sharf[досье] посмотрите на www.ssrtech.com. по-моему вы идете по тому же пути.
Powered by POEM™ Engine Copyright © 2002-2005