# точка входа
состояние = контроллер(входные пар-ры)
результат = выполнить(состояние)
вывод(результата)
Создание CSM – поделимся опытом?
Есть у меня собственная система, которую писал и совершенствовал около года. Написана оная на Perl + PostgreSQL. Полноценной СУК мою разработку назвать нельзя – фактически это движок для быстрого создания CGI приложений, который существенно облегчает мне жизнь, + несколько модулей (новости, статьи, статистика, ссылки и т.д.). Все основывается на использовании шаблонов, текстов замен, редактируемых сообщений и настроек.
Недавно получил заказ на создание СУК для сайта одного из Украинских телевизионных каналов. Собственно, ничего нового: все те же новости, голосования, анонсы, статьи и т.д. Естественно, перед тем как что-либо делать, нужно ознакомится с уже готовыми решениями. Так и поступил. После просмотра первых 40 ссылок, которые выдал Яндекс на запрос "Системы управления контентом", пришел в некоторое замешательство. Во-первых, было найдено лишь одно стоящее решение (http://www.bitrix.ru/ru/products/sitemanager/). Все остальное было либо сыро до безобразия, либо имело функциональность типа: добавить раздел, загрузить в него страницу, вывести меню. Во-вторых, почти все СУК были написаны на PHP. При этом в достоинствах гордо красовалась: "супер скорость работы" (куда там Perl, mod_perl и FastCGI).
Собственно, хотелось бы поделится опытом с теми, кто писал CSM. Так сказать, себя показать, на других посмотреть.
Недавно получил заказ на создание СУК для сайта одного из Украинских телевизионных каналов. Собственно, ничего нового: все те же новости, голосования, анонсы, статьи и т.д. Естественно, перед тем как что-либо делать, нужно ознакомится с уже готовыми решениями. Так и поступил. После просмотра первых 40 ссылок, которые выдал Яндекс на запрос "Системы управления контентом", пришел в некоторое замешательство. Во-первых, было найдено лишь одно стоящее решение (http://www.bitrix.ru/ru/products/sitemanager/). Все остальное было либо сыро до безобразия, либо имело функциональность типа: добавить раздел, загрузить в него страницу, вывести меню. Во-вторых, почти все СУК были написаны на PHP. При этом в достоинствах гордо красовалась: "супер скорость работы" (куда там Perl, mod_perl и FastCGI).
Собственно, хотелось бы поделится опытом с теми, кто писал CSM. Так сказать, себя показать, на других посмотреть.
Цитата:
Originally posted by 2NetFly
Собственно, хотелось бы поделится опытом с теми, кто писал CSM. Так сказать, себя показать, на других посмотреть.
Собственно, хотелось бы поделится опытом с теми, кто писал CSM. Так сказать, себя показать, на других посмотреть.
Мне не раз приходилось писать писать CMS (я всю жизнь думал, что CMS а не CSM). Честно говоря занятие достаточно противное, ничего сложного - сплошной кодинг. Главно продумать структуру и модульность а остальное - дело техники.
Можно написать систему которая будет подходить 90% всех сайтов в интернете, но к моему великому счастью, на мою долю выпадают оставшиеся 10% :) Люблю нетривиальные задачи.
А то что система написана не на PHP это хорошо с точки зрения производительности, но большинство пользователей не смогут ей воспользоваться, так как работая с PHP понятия не имею что такое CGI.
Я не думаю, что СУК – это тривиальная задача. Сколько решений столько и разных подходов. Да, в основе лежит модульность, но реализации могут быть совершенно различны и, следственно, иметь совершенно разные возможности.
Из просмотренных мной систем многие имеют одинаковые недостатки. Вот некоторые из них:
-футер и хеадер задается одинаковый для всех разделов, а установить его для каждого раздела (или для группы разделов) нельзя. То же самое с многими шаблонами – они задаются глобально для всего ресурса.
-блоки (например, последние новости или поступления в разделы) устанавливаются в хеадер и одинаковы для всех разделов. Нельзя отображать их в других шаблонах, нельзя изменять их количество и внешний вид для каждого раздела (например, на главной странице я хочу блок с 10 последними новостями с датой в формате ДД-ММ-ГГ, а в разделе статей – последние 5 новостей с датой в другом формате).
-нет доступа к редактированию многих шаблонов и делать это приходится вручную.
CGI – это интерфейс ;=) PHP его использует точно так же, как и Perl. А СУК для того и пишется, чтоб пользователь мог делать все, что необходимо через панель администрирования, не заботясь о том, на чем она написана.
Из просмотренных мной систем многие имеют одинаковые недостатки. Вот некоторые из них:
-футер и хеадер задается одинаковый для всех разделов, а установить его для каждого раздела (или для группы разделов) нельзя. То же самое с многими шаблонами – они задаются глобально для всего ресурса.
-блоки (например, последние новости или поступления в разделы) устанавливаются в хеадер и одинаковы для всех разделов. Нельзя отображать их в других шаблонах, нельзя изменять их количество и внешний вид для каждого раздела (например, на главной странице я хочу блок с 10 последними новостями с датой в формате ДД-ММ-ГГ, а в разделе статей – последние 5 новостей с датой в другом формате).
-нет доступа к редактированию многих шаблонов и делать это приходится вручную.
CGI – это интерфейс ;=) PHP его использует точно так же, как и Perl. А СУК для того и пишется, чтоб пользователь мог делать все, что необходимо через панель администрирования, не заботясь о том, на чем она написана.
Лучшая CSM - написанная самим собой - факт, сколько не ищи скрипты, в конце приходится писать самому - сэ ля ви... 8)
Цитата:
Я не думаю, что СУК – это тривиальная задача. Сколько решений столько и разных подходов. Да, в основе лежит модульность, но реализации могут быть совершенно различны и, следственно, иметь совершенно разные возможности.
C этим спорить никто не будет. Здесь были названы цифири (90/10). Думается что они явно завышены. Ведь на самом деле, задача создании полнофункциональной системы управления контентом решающая широкий круг задач - не формализована. Есть частные решения, система для создания представительства/магазина/etc. Каждая из них решает специфичные задачи. Но если, вдруг, потребуется внести изменения в функциональность (или дизайн), то без разбирающегося человека сделать это быдет сложно.
Ну вот, например, есть проект по созданию торговой точки в сети icdevgroup.org В доках написано, что мол все что хотите то и делайте с помощию нашей разработки. Но блин, для того чтобы кастомизировать этот проект под свои нужды пройдет немало времени по ознакомлению с руководством. Да и вообще у этих ребят построен бизнес на обучении создания магазинов.
Так что думаю надо трезво оценивать системы управления контентом всовокупности: решает ли она задачичи конкретного заказчика, развертывание системы, обучение, сопровождение, etc...
В идеале, система управления контентом видится этаким мышиным ;)= (с точки зрения редактора сайта) приложением, в котором все основные операции были би привычны. т.е. есть окошко, которое можно таскать, закрывать, элементы меню, (File, Edit, etc) которые тоже выполняют понятные и повседневные действия. И в том же духе.
Если интересно,(нада ж себя показать ;)= на картинке показан мое видение реализации функциональной части. Скрипт позволяет проводить основные операции над пользователями.
Цитата:
Про ссылки в первом посте
...
После просмотра первых 40 ссылок, которые выдал Яндекс на запрос "Системы управления контентом", пришел в некоторое замешательство.
...
...
После просмотра первых 40 ссылок, которые выдал Яндекс на запрос "Системы управления контентом", пришел в некоторое замешательство.
...
В новостях на internet.ru на прошлой неделе было о создании сайта на котором размещена информация о CMS. (Прямую ссылки привести не могу, т.к. мало филок осталось :(=
Цитата:
При этом в достоинствах гордо красовалась: "супер скорость работы"
;)=
[QUOTE]
Лучшая CSM - написанная самим собой - факт, сколько не ищи скрипты, в конце приходится писать самому - сэ ля ви..
[/QUTE]
Здесь, скорее, интересен сам подход к реализации, а не программирование.
ReDrum, насчет мышиного приложения – согласен. Причем, зачастую, от этого страдает функциональность.
Я сейчас пытаюсь реализовать СУК, которая без правки кода может быть перепрограммирована под нужды пользователя. Попытаюсь объяснить, что я имею в виду.
Предположим, есть стандартный модуль новостей и в нем определен набор функций, используемый для создания блоков на странице. Допустим, среди этих функций есть функция:
news_theme_list(шаблон_полный, шаблон_поля, лимит_от, лимит_до, сортировать_по, порядок_сортировки)
Функция выполняет запрос:
SELECT * FROM NEWS ORDER BY сортировать_по порядок_сортировки LIMIT лимит_от, лимит_до
Затем для каждой выбранной строки она заменяет параметры в шаблон_поля на значения из таблицы и объединяет с предыдущей замененной строкой. И, наконец, возвращает все замененные строки в шаблоне шаблон_полный.
Догадываюсь, что никто ничего не понял, поэтому приведу пример шаблонов и результат выполнения функции:
шаблон_полный:
Последние 5 новостей:
--
%% шаблон_поля%%
--
шаблон_поля:
%%дата%% - %%тема_новости%%
Вызов функции:
news_theme_list(шаблон_полный, шаблон_поля, 0, 3, дата, desc)
Результат:
Последние 5 новостей:
--
[10-10-02] - тема1
[09-10-02] - тема2
[01-10-02] - тема3
[10-09-02] – тема4
--
Далее, пользователь, через веб интерфейс, используя заданный набора функций, может самостоятельно определить блоки, которые будут установлены на сайте. При этом, он может указывать как различные параметры для выборки, так и различные шаблоны. Это позволит выводить совершенно разные блоки. Например:
последнюю новость (с полным текстом, датой и т.д.)
список последних новостей
список тем
и т.д. и т.п.
Фактически, опередив в модуле новостей 3-4 функции можно обеспечить полную гибкость его работы. А если реализовать возможность импорта / экспорта функций из разных модулей и принцип "наследования" блоков другими модулями можно добиться хороших результатов.
Я сейчас развиваю эту идею и достиг некоторых успехов. Если кто-то хочет присоединится к разработке – милости прошу.
Я сейчас пытаюсь реализовать СУК, которая без правки кода может быть перепрограммирована под нужды пользователя. Попытаюсь объяснить, что я имею в виду.
Предположим, есть стандартный модуль новостей и в нем определен набор функций, используемый для создания блоков на странице. Допустим, среди этих функций есть функция:
news_theme_list(шаблон_полный, шаблон_поля, лимит_от, лимит_до, сортировать_по, порядок_сортировки)
Функция выполняет запрос:
SELECT * FROM NEWS ORDER BY сортировать_по порядок_сортировки LIMIT лимит_от, лимит_до
Затем для каждой выбранной строки она заменяет параметры в шаблон_поля на значения из таблицы и объединяет с предыдущей замененной строкой. И, наконец, возвращает все замененные строки в шаблоне шаблон_полный.
Догадываюсь, что никто ничего не понял, поэтому приведу пример шаблонов и результат выполнения функции:
шаблон_полный:
Последние 5 новостей:
--
%% шаблон_поля%%
--
шаблон_поля:
%%дата%% - %%тема_новости%%
Вызов функции:
news_theme_list(шаблон_полный, шаблон_поля, 0, 3, дата, desc)
Результат:
Последние 5 новостей:
--
[10-10-02] - тема1
[09-10-02] - тема2
[01-10-02] - тема3
[10-09-02] – тема4
--
Далее, пользователь, через веб интерфейс, используя заданный набора функций, может самостоятельно определить блоки, которые будут установлены на сайте. При этом, он может указывать как различные параметры для выборки, так и различные шаблоны. Это позволит выводить совершенно разные блоки. Например:
последнюю новость (с полным текстом, датой и т.д.)
список последних новостей
список тем
и т.д. и т.п.
Фактически, опередив в модуле новостей 3-4 функции можно обеспечить полную гибкость его работы. А если реализовать возможность импорта / экспорта функций из разных модулей и принцип "наследования" блоков другими модулями можно добиться хороших результатов.
Я сейчас развиваю эту идею и достиг некоторых успехов. Если кто-то хочет присоединится к разработке – милости прошу.
Цитата:
Originally posted by 2NetFly
ReDrum, насчет мышиного приложения – согласен. Причем, зачастую, от этого страдает функциональность.
ReDrum, насчет мышиного приложения – согласен. Причем, зачастую, от этого страдает функциональность.
Не мухи отдельно, котлеты отдельно. ;)=
Поясняю, что имею ввиду.
Возмкм к примеру ПЭВМ. Так вот, с точки зрения техника машина имеет - исполнительный механизм, систему управления, блок отображения. Вобщем такой внутренней структуре подвержены многие приборы ;)=
Так вот, перенося модель на программирование, получается, что
исполнительный механизм - это код, ответственный за реализацию процесса.
система управления - контроллер, черный ящик, который сообщает, что нужно выполнить такое действие.
Блок отображения - это какие нить визуальная часть.
Так вот работа выглядит где то так
Код:
т.е. при запуске программы отределяется состояние, необходимо обработать выбранное состояние и показать результат выполнения.
т.о. функциональная (исполнительная) часть развязана от интерфейса.
Цитата:
Я сейчас пытаюсь реализовать СУК, которая без правки кода может быть перепрограммирована под нужды пользователя. Попытаюсь объяснить, что я имею в виду.
...
пользователь, через веб интерфейс, используя заданный набора функций, может самостоятельно определить блоки, которые будут установлены на сайте. При этом, он может указывать как различные параметры для выборки, так и различные шаблоны. Это позволит выводить совершенно разные блоки. Например:
последнюю новость (с полным текстом, датой и т.д.)
Идея то понятная, но только с наверное стоит рассмотреть подход к реализации не с точки зрения реализации, а вообще описать сам процесс программирования. т.е. не снизу вверх, а наоборот. для того что бы избежать ошибок при разработке структуры самой системы.
И такой вопрос, уже касательный программирования.
Я так понял ты используешь собственные шаблоны, ну и соотвутсвенно есть набор решений, позволяющих разбирать эти темплейты.
Чем вызвано татое решение? т.е. почему ты отказался от использования HTML::Template (Template Tollkit || еще нескольких готовых решений)???
Цитата:
Originally posted by ReDrum
Идея то понятная, но только с наверное стоит рассмотреть подход к реализации не с точки зрения реализации, а вообще описать сам процесс программирования. т.е. не снизу вверх, а наоборот. для того что бы избежать ошибок при разработке структуры самой системы.
И такой вопрос, уже касательный программирования.
Я так понял ты используешь собственные шаблоны, ну и соотвутсвенно есть набор решений, позволяющих разбирать эти темплейты.
Чем вызвано татое решение? т.е. почему ты отказался от использования HTML::Template (Template Tollkit || еще нескольких готовых решений)???
Идея то понятная, но только с наверное стоит рассмотреть подход к реализации не с точки зрения реализации, а вообще описать сам процесс программирования. т.е. не снизу вверх, а наоборот. для того что бы избежать ошибок при разработке структуры самой системы.
И такой вопрос, уже касательный программирования.
Я так понял ты используешь собственные шаблоны, ну и соотвутсвенно есть набор решений, позволяющих разбирать эти темплейты.
Чем вызвано татое решение? т.е. почему ты отказался от использования HTML::Template (Template Tollkit || еще нескольких готовых решений)???
Был просто приведен пример, дабы стало понятно, о чем я говорю. Фактически, на бумаге практически все уже готово. На "додумывание" уйдет недельку-полторы, потом попробую прикрутить новое к своей разработке.
Решение использовать свои шаблоны вызвано тем, что писалось все с нуля и я не надеялся, что мои наработки пригодятся мне в других проектах и что я буду дальше их развивать. В данный момент меня полностью устраивает набор функций, которые я написал. Кроме того, у меня все работает не только на шаблонах, но и на заменах и настройках. Для интеграции с готовыми модулями все равно пришлось бы затратить некоторое количество времени и усилий. Хотя, я не исключаю, что в будущем перепишу все под HTML::Template. Кстати, от CGI.pm я тоже отказался ;=) Вместо него пользую крохотный cgi-lib.
2NetFly давай через месяц другой вернемся к этой теме.
Короче вот мой контакт ReDrum[at]newmail.ru
Думаю, будет интересно обменяться кодом.
Короче вот мой контакт ReDrum[at]newmail.ru
Думаю, будет интересно обменяться кодом.
Цитата:
Originally posted by ReDrum
И такой вопрос, уже касательный программирования.
Я так понял ты используешь собственные шаблоны, ну и соотвутсвенно есть набор решений, позволяющих разбирать эти темплейты.
Чем вызвано татое решение? т.е. почему ты отказался от использования HTML::Template (Template Tollkit || еще нескольких готовых решений)???
И такой вопрос, уже касательный программирования.
Я так понял ты используешь собственные шаблоны, ну и соотвутсвенно есть набор решений, позволяющих разбирать эти темплейты.
Чем вызвано татое решение? т.е. почему ты отказался от использования HTML::Template (Template Tollkit || еще нескольких готовых решений)???
Мне вот интересно почему юзаются впринципи шаблоны, сапальные ли это или такие монстры как (HTML::Template ) почему не XML ?
Граждане, объясните мне чем Вам собственно не нравиться CMS на пхп?? Чем так пхп то не нравиться??
Если язык проще Перла ИМХО это еще не значит, что он хуже....
Если язык проще Перла ИМХО это еще не значит, что он хуже....
Цитата:
Originally posted by Joker
Мне вот интересно почему юзаются впринципи шаблоны, сапальные ли это или такие монстры как (HTML::Template ) почему не XML ?
Мне вот интересно почему юзаются впринципи шаблоны, сапальные ли это или такие монстры как (HTML::Template ) почему не XML ?
XML использовать, нет увольте. Возни много, и писанины. Чего я на самом деле нелюблю так это писанину.
Хотя по большому счету принцип работы одинакров, какая то структура покрывается какой то другой.
HTML::Template - может шарить в памяти шаблоны.
Цитата:
Originally posted by Lsd[52r]
Граждане, объясните мне чем Вам собственно не нравиться CMS на пхп?? Чем так пхп то не нравиться??
Если язык проще Перла ИМХО это еще не значит, что он хуже....
Граждане, объясните мне чем Вам собственно не нравиться CMS на пхп?? Чем так пхп то не нравиться??
Если язык проще Перла ИМХО это еще не значит, что он хуже....
Если меня Alone c 2NetFly дополнят
1. В php нельзя получить информацию с SDTIN'а. На перле можно сделать оболочку для пхп а наоборот нельзя.
2. В перле есть срезы массивов (массив через массив). В php нельзя задать массив как (1 .. 10).
3. При аплоаде файла его нельзя получить в переменную. Нужно обязательно сохранить в файл в /tmp, а потом с диска
прочитать (уроды).
4. Встроенные регулярки. =~m/ ... / возвращает массив.
5. В пхп нет таких функций как map и grep. В перле функции с подобным синтаксисом можно определять самому.
6. Огромное число готовых модулей, многие из которых написаны полностью на перле (важно для халявного хостинга).
7. Perl не смешивается принудительно с хтмл.
8. tie. Одно из применений, связывание потоков.
9. Экспорт переменных и создание их синонимов *{"$pack_name".'::'."$var_name"}=$value
10. В перле нет тупой встроенной реализации сессий, как в пхп.
11. В перле есть анонимные функции и их непосредственный вызов как sub{ ... }->().
12. AUTOLOAD и $AUTOLOAD.
13. Регулярки компилятся при компиляции скрипта или через qr/ ... /.
14. DBI/DBD.
15. Конструктор не обязательно должен совпадать с именем класса. Объект создается через bless.
16. Безопасное выполнение через eval{ ... }.
17. Кстати, php ни чем не лучше C.
18. PERL позволяет использовать две из встроенных функций в качестве леводопустимых выражений, это функции substr и keys.
19. goto ($SomeLabel1, $SomeLabel2, $SomeLabel3) [$i]; goto &SomeFunction();
20. Константа __PACKAGE__ позволяет не привязываться к имени пакета.
21. Документирование с помощью =head<1,2> =cut
22. Возможность изменять переданный аргумент без ссылки на него sub{ $_[1]='1000'; }.
23. Возможность переопределения $SIG{'__DIE__'}, $SIG{'__WARN__'}
imho
2ReDrum
хех порадовал :)
дополнить не смогу, я плохо знаю(да что там, совсем не знаю) php, так на досуге немного читаю... пишу...
насчет 4. в php есть функция позволяющая загонять в массив.
5. Уверен? уж больно grep полезная функция... должна быть :)
а вообще тема называется "Создание CSM – поделимся опытом?" а не "Вечная история. perl vs php. Раунд 38696. Гонг..."
Будь бы я модером я бы стер месагу Lsd[52r] за разжигания меж-языковый розни :)...
а ReDrum-у выговор за развитие флейма :D
2Joker
XML это конечно здорово...
но работать с ним будет заказчик а им даже самы простой шаблонизатор бывает тяжело объяснить...
хех порадовал :)
дополнить не смогу, я плохо знаю(да что там, совсем не знаю) php, так на досуге немного читаю... пишу...
насчет 4. в php есть функция позволяющая загонять в массив.
5. Уверен? уж больно grep полезная функция... должна быть :)
а вообще тема называется "Создание CSM – поделимся опытом?" а не "Вечная история. perl vs php. Раунд 38696. Гонг..."
Будь бы я модером я бы стер месагу Lsd[52r] за разжигания меж-языковый розни :)...
а ReDrum-у выговор за развитие флейма :D
2Joker
XML это конечно здорово...
но работать с ним будет заказчик а им даже самы простой шаблонизатор бывает тяжело объяснить...
Цитата:
Originally posted by Alone
2ReDrum
2Joker
XML это конечно здорово...
но работать с ним будет заказчик а им даже самы простой шаблонизатор бывает тяжело объяснить...
2ReDrum
2Joker
XML это конечно здорово...
но работать с ним будет заказчик а им даже самы простой шаблонизатор бывает тяжело объяснить...
В том то вся соль, что хмль некому править не придется, все делается через веб управление.
А в дальнейшем ХМЛ шаблоны смогет править любой программист, а не изучать чужие шаблоны..
Флейм по поводу пхп вс перл:
http://forum.codenet.ru/showthread.php?s=&threadid=14723
Цитата:
Originally posted by Joker
В том то вся соль, что хмль некому править не придется, все делается через веб управление.
А в дальнейшем ХМЛ шаблоны смогет править любой программист, а не изучать чужие шаблоны..
s=&threadid=14723[/url]
В том то вся соль, что хмль некому править не придется, все делается через веб управление.
А в дальнейшем ХМЛ шаблоны смогет править любой программист, а не изучать чужие шаблоны..
s=&threadid=14723[/url]
Не думаю, что XML – лучший вариант шаблонизации. А изучать чужие шаблоны – дело не особо сложное, даже если использовать рекурсивные замены.
Цитата:
Originally posted by 2NetFly
Не думаю, что XML – лучший вариант шаблонизации. А изучать чужие шаблоны – дело не особо сложное, даже если использовать рекурсивные замены.
Не думаю, что XML – лучший вариант шаблонизации. А изучать чужие шаблоны – дело не особо сложное, даже если использовать рекурсивные замены.
Абсолютно не лучший, особенно если есть желание предоставлять сервис изменения шаблонов будущим пользователям/заказчикам .... От слова ХМЛ многие из них впадают в ступор.... :)
кАвтору. А что конкретно тебя интересует в создании в процессе ЦМС. К этому неблагодарному делу я приобщился 3,5 года назад. Последний проект
http://www.microsoft.com/resources/casestudies/casestudy.asp?CaseStudyID=14937