Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Интернет » Web-программирование » Принципы построения CMS (КМС, Система Управления Сайтом).

Модерирует : Cheery

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6

Открыть новую тему     Написать ответ в эту тему

edogs

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
<0.5*offtop>
6epcepk

Цитата:
PHP-Nuke это отдельная история (: Вот одна из последних уязвимостей (:

угу. история отдельная. уязвимость-то (как и большинство публикуемых о нюке) не действующая. Кроме уязвимостей в пхпбб, ни одной "нюковской" уязвимости срабатывающей при хозяине нюки с головой (т.е. озаботился поставить правильно) мы за последние 2 года не видели. Хотя читаем внимательно.
</0.5*offtop>
 
По теме.
Мы бы сказали так. Структура и принцип построения цмс в первую очередь всегда зависит от её целей. И сама мысль описать принципы построения цмс в отрыве от целей цмс нам кажется крамольной. Более того, мы бы сказали что "неправильных" путей построения цмс не существует (кроме грубых ошибок).
 
Модульная архитектура... кто-то назовет минусом. Забывая о том, что любая задача которую этот кто-то перед собой поставит реализуема в рамках модуля, а вот наоборот уже на порядок сложнее.  
 
Принцип "функциональность в жертву скорости" - а как ещё если хочется привлечь много сторонних разработчиков и сделать цмс популярной? Скорость всегда означает узкие рамки решения задачи. Или громоздкость цмс. Ведь даже реализация макс. скорости при поддержке нескольких типов БД это уже означает соответствующее количество кода построения этих запросов - по штуке на каждый тип.
 

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

И какое логичное продолжение этого?  
Разрастание библиотеки функций или использование метода копи-пасте. Второе более чревато ошибками. Первое... возвращаемся к принципу "функциональность в жертву скорости".
А ведь библиотека функций (солидная) по сути и есть синоним модуля. Если обобщить немного более смело.
 

Цитата:
то написание проекта индивидуально под нужды заказчика исключает в бОльшей вероятности обнаружения этих "дыр" (пока невидимых) злоумышлинниками.

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

Цитата:
Нужно иметь какой то стандартный набор функций.... ядро ...  
А уже потом подстраивать все под нужный проэкт...

Как бы логично, но немного общо и очевидно
Тут мы бы сказали что стандартный апи должен быть минимальным. wysiwyg. Должен быть солидный модуль контента. Это покроет 90% нужд большинства заказчиков Остальное корректируется не сложно.
А вот модульная структура, позволит именно "настраивать", а не "дописывать" под нужный проект это. Ставишь что надо и сдаешь. Никаких проблем. Вопрос лишь в том, что бы модули нужные написать с умом
 
Кстати, мы бы предположили что будущее таки за системами a-la codecharge.com . Имхо именно такой подход (подход!) позволит совместить функциональность+скорость и избежать ошибок копипасте.
 
P.S.: сорри что немного сумбурно
P.P.S.: самое печальное что зачастую разработчики цмс не всегда интересуются нуждами заказчика при разработке структуры и т.д.
P.P.P.S.: из нашей коллекции
npj.ru/slach/good_cms
livejournal.com/users/xekc/

Всего записей: 1777 | Зарегистр. 25-07-2004 | Отправлено: 06:11 23-01-2006
N Sensey N



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
и самое главное - заказчику пофиг как ты кмску напишешь.. главное тоб работало

----------
sPaiz-Nuke - Free PHP CMS Web Design and Development Портал для израильтян

Всего записей: 1409 | Зарегистр. 01-10-2002 | Отправлено: 14:43 23-01-2006
Farkhad



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Хотел бы поделиться с народом такой ссылкой: Пишу CMS (мысли вслух, концепции, идеи, решения)
 
Там очень много всего и причем по теме.

Всего записей: 731 | Зарегистр. 03-08-2001 | Отправлено: 14:45 23-01-2006
edogs

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
N Sensey N

Цитата:
и самое главное - заказчику пофиг как ты кмску напишешь.. главное тоб работало  

во-во. где-то правильно было подмечено, что проблема у всех цмс, что их пишут программисты а вот если бы их писали пользователи/администраторы, то всё было бы совсем по другому.

Всего записей: 1777 | Зарегистр. 25-07-2004 | Отправлено: 16:56 23-01-2006
UncoNNecteD



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Какая разница - подключаешь ты модуль или же вставляешь в основной файл инородную функцию.  
Че за бред.

----------
-= Я тут чертовски давно =-

Всего записей: 4040 | Зарегистр. 21-03-2002 | Отправлено: 17:18 23-01-2006
6epcepk



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
edogs

Цитата:
хотелось бы определиться с термином "индивидуально". если этот термин подразумевает использование единой библиотеки, и заточку их под заказчика, то это совсем не "индивидуально", а скорее "поставлено на поток" и на увеличении безопасности это вряд ли скажется.

Скорее в этой мысли имелось в виду, что исходник кода будет иметь только разработчик и заказчик (в виде установленной системы).
 
 

Цитата:
Хотел бы поделиться с народом такой ссылкой: Пишу CMS (мысли вслух, концепции, идеи, решения)  
 
Там очень много всего и причем по теме.

 
Осилил пока 1/9 ... но на мой взгляд, если задумка автора будет работать, то возможно это будет верх построения КМС (?) ...
 
Даже одно "голое" его ядро вызывает открытие рта.
 
Как вывод сделал, что в ближайшие N лет врятли стоит приступать к реализации описанных им принципов - не позубам пока (:

----------
comming soon..

Всего записей: 2603 | Зарегистр. 02-05-2003 | Отправлено: 19:17 23-01-2006
Brodyaga



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Farkhad
Неотрывно читаю это великолепие, идея заставила отойти от компа и протереть глаза...
в ближайшее время постараюсь хоть 1/3 ядра реализовать, но это будет...
Вроде русский язык,но все равно читать трудно из-за революционности идеи.
Тем более когда идеи прерываются критикой по поводу русского языка...
 
Но немного недопонимаю, реализация ожидается исключительно в консольном виде?Неужели Секретарше проще ввести команды, чем кликать кнопки( в разумном их кол-ве), пока пытаюсь найти обьяснение..

----------
Damn Metal

Всего записей: 2713 | Зарегистр. 07-01-2006 | Отправлено: 19:29 23-01-2006 | Исправлено: Brodyaga, 19:31 23-01-2006
6epcepk



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Brodyaga
Видимо ты мало прочитал там ... (или я мало ...), он планирует (уже реализовал?) на Делфи, то есть там будет полностью Draw&Drop.

----------
comming soon..

Всего записей: 2603 | Зарегистр. 02-05-2003 | Отправлено: 20:11 23-01-2006
Brodyaga



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
6epcepk
Клиентская часть.
Я не собираюсь углубляться в Прикладное программирование, сейчас по крайней мере.
Серверная часть реализована на РНР.
Он уже реализовал ядро, сейчас отбивается от нападок типа "не успеешь, не смогешь, загнешься".
Посмотрим что будет дальше, если я правильно улавливаю суть, пока ядро и серверная часть пишется на РНР

----------
Damn Metal

Всего записей: 2713 | Зарегистр. 07-01-2006 | Отправлено: 20:17 23-01-2006
Farkhad



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Когда я это все это дело читал (до меня долго доходило, что означает слово "те"), то я понял что человек решил юзать либо XUL либо Delphi. Потом от XUL он отказался из-за багов и ограничения на браузер (технология только для Mozilla).  
Короче идея XML RPC (Remote Procedure Call), вроде на ней он остановился.
Давно там ничего не читал, поэтому не в курсе на чем он остановился.
 
Талантливый чувак , ничего не скажешь

Всего записей: 731 | Зарегистр. 03-08-2001 | Отправлено: 21:00 23-01-2006
Brodyaga



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Талантливый, единственная нерациональность на мой взгляд это разделение маленький сайт-большой сайт, и как следствие использование/нет БД.
Как будет осуществляться перенос на БД?
Мне кажется что надо решить Файлы vs БД и остаться при своем.

----------
Damn Metal

Всего записей: 2713 | Зарегистр. 07-01-2006 | Отправлено: 21:08 23-01-2006
6epcepk



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Brodyaga
На мой взгляд все логично. Он сам приводит пример, что если это будет всего лишь персональная страничка, то нет смысла использовать базы данных.
 
 
Я прочитал все, естественно не во все моменты вникал.
 
С ходу советую прочитать:
 
Шаблоны:
http://xpoint.ru/forums/development/analysis/thread/28649.xhtml#283437
http://xpoint.ru/forums/development/analysis/thread/28649.xhtml#303596
 
Безопасность:
http://xpoint.ru/forums/development/analysis/thread/28649.xhtml#293665
 
 
Кварко Атомарная Модель Обьектов
 
Цель- создать механизмы которые позволят "клепать" как на конвеере , форумы, гостевые, регистрацию юзеров, карзину, листинги и директории...
 
http://xpoint.ru/forums/development/analysis/thread/28649.xhtml#286462
http://xpoint.ru/forums/development/analysis/thread/28649.xhtml#306448
 
 
Я в шоке. Хотелось бы услышать комментарии Cheery ...

----------
comming soon..

Всего записей: 2603 | Зарегистр. 02-05-2003 | Отправлено: 00:34 24-01-2006 | Исправлено: 6epcepk, 00:35 24-01-2006
Farkhad



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Brodyaga
За универсализм всегда платишь скоростью

Всего записей: 731 | Зарегистр. 03-08-2001 | Отправлено: 11:49 24-01-2006
edogs

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
6epcepk

Цитата:
Цель- создать механизмы которые позволят "клепать" как на конвеере , форумы, гостевые, регистрацию юзеров, карзину, листинги и директории...  
 

Берем обычную, банальную воблу.
форум есть? есть
гостевая? отдельный раздел форума и вперед
регистрация юзеров? есть
корзина? = подписка на темы, избранные сообщения - есть
листинги? - форумы - есть
директории? - делаем разделы форумов - есть
блог? - делаем раздел форума - есть
фотогалерея? - делаем раздел форума - есть
новостная лента? - та же фигня
..
все это ДАВНО уже сделано. вопрос просто в том доходит ли до сайтовладельца как это использовать или нет. порталы на форумах можно посмотреть... ну ничего там эдакого нет... форум с разными настройками и все
 
Добавлено:

Цитата:
Хотел бы поделиться с народом такой ссылкой: Пишу CMS (мысли вслух, концепции, идеи, решения)  

Осилили весь текст.
Наша имха - получится ну ОЧЕНЬ тяжелый код, либо нестандартизированный, либо негибкий.  
Если "по верхам". Ну допустим идея дать возможность подключать разные шаблонные движки... конечно круто... широко, функционально, на на кой черт это нужно? А что делать создателям модулей - писать под каждый? Или цмс должно предоставлять единый стандарт написания шаблонов для разных шаблонных движков?
Имхо автор излагает в стиле "мне не удается забивать отверткой гвозди, поэтому создам я свою отвертку для забивания гвоздей, намного более удобную, посмотрите какая классная отвертка получается"... только нам непонятно почему не создать молоток...

Всего записей: 1777 | Зарегистр. 25-07-2004 | Отправлено: 15:55 24-01-2006
Danil Lab



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
2all
Я тож свой движок писал, (см мой сайт в профиле) с расширением возможностей
сталкнулся с тяжёлым и корявым кодом. (как я потом понял)
Ща делаю на основе CuteNews.RU, код легкий легко модифицируемый, плагины поддерживает, вобщем то что надо для основы.

Всего записей: 269 | Зарегистр. 12-06-2005 | Отправлено: 18:08 24-01-2006
Brodyaga



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
Имхо автор излагает в стиле "мне не удается забивать отверткой гвозди, поэтому создам я свою отвертку для забивания гвоздей, намного более удобную, посмотрите какая классная отвертка получается"... только нам непонятно почему не создать молоток...

Вероятно потому что молоток слишком тяжел,и приспособлен к однообразным задачам, например закрутить болт нельзя молотком.
Это как перебор-недобор.
Чаще немного недобрать лучше чем перебрать.
Тем более если создана отвертка, которая уже приспособлена к определенной задаче, то прививание её способности забивать гвозди и есть модульная расширяемость.
 
Ведь возьмите мамбо, TYPO3 их нельзя переделать так как представляет нам автор, то есть загружать на страницу несколько модулей, 1 модуль несколько раз и так далее.А если можно, то на это накладываются ограничения, т.к. главная мысль треда, что ядро не знает о существовании других модулей, так же как и модули не знают друг о друге.Обычная рекурсия, в результате которых никаких ограничений не накладывается и добиваемся бесконечной (ну ладно, слишком сильно сказано) расширяемости ядра.
 


----------
Damn Metal

Всего записей: 2713 | Зарегистр. 07-01-2006 | Отправлено: 18:48 24-01-2006
Ternik



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Тем более если создана отвертка, которая уже приспособлена к определенной задаче, то прививание её способности забивать гвозди и есть модульная расширяемость.

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

Цитата:
Разрастание библиотеки функций или использование метода копи-пасте. Второе более чревато ошибками. Первое... возвращаемся к принципу "функциональность в жертву скорости".
А ведь библиотека функций (солидная) по сути и есть синоним модуля. Если обобщить немного более смело.  

естественно, дык зачем писать свои собственные модули под ядро, которое написано на ПХП, вместо того чтобы писать сразу под ядро ПХП, без обходных путей. Я вообщем-то это и хотел сказать и ты меня понял.
 

Цитата:
Это покроет 90% нужд большинства заказчиков Остальное корректируется не сложно.  

Ок, какие функции вы напишите, которых не будет в связке PHP+MySQL+Smarty.php.net + PEAR LIB.
 

Цитата:
 Даже одно "голое" его ядро вызывает открытие рта.  

в принципе немного терпения и вдохновения и http://pear.php.net/package/HTML_AJAX
 
или вы хотите написать расширяему по функциональности КМС, которой может пользоваца даже обычный юзер-ламух? т.е. особо не напрягаясь, ну вот и получица PHP-nuke. А что до того что если с головой дружить, то это да. Но можно ведь и плацдарм для своих скриптов сделать, и с головой писать новые, какие хошь. Связка одна  = MySQL, следовательно проблем в репликации данных не будет.
 

Всего записей: 763 | Зарегистр. 25-09-2002 | Отправлено: 20:01 24-01-2006
edogs

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Brodyaga

Цитата:
Ведь возьмите мамбо, TYPO3 их нельзя переделать так как представляет нам автор, то есть загружать на страницу несколько модулей

А блоки можно. Не в названии ведь суть, не так ли?

Цитата:
главная мысль треда, что ядро не знает о существовании других модулей, так же как и модули не знают друг о друге

Вот тут не поняли. Это что, что-то новое? В нюке модуль News например тоже без понятия о модуле... допустим Forums.
Только мы бы сказали тут наоборот - отсутствие знаний друг о друге делает систему разбитой на отдельный части и не работающей как единое целое. Не можем поставить тут +

Цитата:
Тем более если создана отвертка, которая уже приспособлена к определенной задаче, то прививание её способности забивать гвозди и есть модульная расширяемость.  

Допустим это верно. Ну так ведь в мамбе на которую ссылается автор как н абяку так и есть. В этом и суть модульной расширяемости мамбы.
Ну а если высказать лично наше мнение. Вы попробуйте продать в любую профессиональную автомастерскую помесь отвертки с молотком... вам расскажут о неверности подхода просто и доступно

Цитата:
Ок, какие функции вы напишите, которых не будет в связке PHP+MySQL+Smarty.php.net + PEAR LIB.  

Ну, во первых там не будет тормозов smarty
Что касается конкретно ответа на вопрос. Мы считаем что хороший контент модуль, управление юзерами/группами/правами,  и wysiwyg это достаточно общие вещи, они должны входить в ядро цмс. Скорее всего надо включить управление шаблонами.  
А вот всё остальное надо писать под заказчика индивидуально ПОЛНОСТЬЮ.
Форум мы например НЕ считаем нужным включать в состав цмс вообще (по разным причинам, можем объяснить).

Всего записей: 1777 | Зарегистр. 25-07-2004 | Отправлено: 20:29 24-01-2006
Brodyaga



Silver Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
Только мы бы сказали тут наоборот - отсутствие знаний друг о друге делает систему разбитой на отдельный части и не работающей как единое целое. Не можем поставить тут +  

Не знание друг о друге подразумевает независмость, в частном случае.
В таком случае и PHP-Nuke разбита на части?И не работает как единое целое?
Я здесь имел ввиду системные модули типа mod_database, модули например новостей получают данные откуда-то, откуда им глубоко пофиг, и в результате мы можем назначить любой модуль типа mod_database передавать данные в на перехват mod_news.

Цитата:
Ну а если высказать лично наше мнение. Вы попробуйте продать в любую профессиональную автомастерскую помесь отвертки с молотком... вам расскажут о неверности подхода просто и доступно

Это как изобрести велосипед с квадратными колесами
Есть где приложиться, зато инструмент получится многосторонний.Ведь нет все же установленных рамок создания CMS за исключением рационализации, и не создания ситуации когда из "пушки по червяку".
Что то меня занесло не туда и не по теме.
 
---------------
 
В таком случае прошу мне разьяснить, есть ли революционность данного подхода?И подход ли это, или просто собирание всего созданного воедино и придания им приятного вида?И приятного ли?
Ternik

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

Требую разьяснения, т.к. всякое изменение не всегда есть извращение, а также улучшение или ухудшение, 3 не дано.
Так что же по вашему, если добавить к отвертке возможность, которая лишь улучшить юзабельность для мастера, т.е. по вашему определению это извращение, оно является ухудшением?
 
----------------===========--------------
 
И вообще мы обсуждаем принципы построения клиент-серверной модели CMS, а не молотки и отвертки, и хоть абстрактное представление и удобнее, но все же не надо забывать, что молоток и CMS разные вещи, из разных областей применения.
 
 
Добавлено:

Цитата:
Вот тут не поняли

Вы пишите от лица нескольких человек, сидящих за одной машиной?

----------
Damn Metal

Всего записей: 2713 | Зарегистр. 07-01-2006 | Отправлено: 21:00 24-01-2006
Ternik



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Требую разьяснения, т.к. всякое изменение не всегда есть извращение, а также улучшение или ухудшение, 3 не дано.  

Ок, если отвертке добавить массу молотка, ей будет сложно крутить. Руки банально будут быстро уставать, а если молотку добавить на обратную сторону отвертку то нечем будет гвозди выковыривать.
 

Цитата:
Ну, во первых там не будет тормозов smarty
Что касается конкретно ответа на вопрос. Мы считаем что хороший контент модуль, управление юзерами/группами/правами,  и wysiwyg это достаточно общие вещи, они должны входить в ядро цмс. Скорее всего надо включить управление шаблонами.  

ок, не буду вдаваться в подробности компиляции и признаю что смарти тормозит. Хотя эта идея не нова и использовалась еще в gossamer-threads::Template, который с успехом использовался в большинстве коммерческих проектов. Какую идею обработки шаблонов можете предложить Вы? Я вот считаю если не шаблоны, то XHTML.  
Я не совсем понял про юзеров и права, это надо разрабатывать общую концепцию в которой должно четко указываться что имеет право делать каждый. И кмс (как програмный код) тут ни причем.  

Цитата:
А вот всё остальное надо писать под заказчика индивидуально ПОЛНОСТЬЮ.

И вот вы пытаетесь доказать что можно писать модульные КМС, которые можно особо не напрягаясь подводить под каждого клиента, вы пожалуйста определитесь.

Цитата:
И вообще мы обсуждаем принципы построения клиент-серверной модели CMS, а не молотки и отвертки, и хоть абстрактное представление и удобнее, но все же не надо забывать, что молоток и CMS разные вещи, из разных областей применения.

между прочим, про молотки и отвертки это был Ваш пост.
 
з.ы. критиковать всегда проще чем предлагать.
 
 
 
 

Всего записей: 763 | Зарегистр. 25-09-2002 | Отправлено: 21:28 24-01-2006
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6

Компьютерный форум Ru.Board » Интернет » Web-программирование » Принципы построения CMS (КМС, Система Управления Сайтом).


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru