-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Кто писал свою CMS - есть вопрос
- Автор темы Savio
- Дата начала
flash-vkv
Новичок
SOAP основан на XML и не как не связан с протоколом обшения
SOAP служит для правельного обмена данными между приложениями (это стандарт), то что я имею ввиду это отсутствие связи как таковой потому как просто пропуская через ядро HTTP запрос к модулю и прибавив к нему +свои данные (GET и POST) ядро не как не накладывает ограничения в случии если использовать SOAP , ядро в таком случии отвечает в выборе модулей(приложений) и растовлении полученных данных в нужном порядке.
Опять повтарюсь смысл подхода в том чтобы отделит код и логику ядра и приложения оставив им канал для взаимодействия, в данном примере по протоколу HTTP , но это можно былобы организовать и на долие высоком уровне, но тогда пришлось бы ограничить рамки темже SOAP. вспомним хотябы MS с их NET подходам.
Поддерживал бы PHP многопоточнось можно былобы увеличить скорость выполнения сборки в моем подходе с HTTP.Незначительно но всеже.
SOAP служит для правельного обмена данными между приложениями (это стандарт), то что я имею ввиду это отсутствие связи как таковой потому как просто пропуская через ядро HTTP запрос к модулю и прибавив к нему +свои данные (GET и POST) ядро не как не накладывает ограничения в случии если использовать SOAP , ядро в таком случии отвечает в выборе модулей(приложений) и растовлении полученных данных в нужном порядке.
Опять повтарюсь смысл подхода в том чтобы отделит код и логику ядра и приложения оставив им канал для взаимодействия, в данном примере по протоколу HTTP , но это можно былобы организовать и на долие высоком уровне, но тогда пришлось бы ограничить рамки темже SOAP. вспомним хотябы MS с их NET подходам.
Поддерживал бы PHP многопоточнось можно былобы увеличить скорость выполнения сборки в моем подходе с HTTP.Незначительно но всеже.
Popoff
popoff.donetsk.ua
ONK
обязательно сделаю, когда появится необходимость
необходимости пока нет, да и дело это в рамках моей системы, кажется, довольно морочное. в отличие от предварительной загрузки - все решилось введением одной таблички и простенькими модификациями скриптов в двух местах - новая фича за полчаса делов пока не свосем ясно, насколько мне от этого лучше, но эту фичу, как и любую другую, можно легко отключить
-~{}~ 04.01.06 11:32:
обязательно сделаю, когда появится необходимость
необходимости пока нет, да и дело это в рамках моей системы, кажется, довольно морочное. в отличие от предварительной загрузки - все решилось введением одной таблички и простенькими модификациями скриптов в двух местах - новая фича за полчаса делов пока не свосем ясно, насколько мне от этого лучше, но эту фичу, как и любую другую, можно легко отключить -~{}~ 04.01.06 11:32:
а потом будем играть в "найдите 10 отличий" %-)
Алексей Пешков
Новичок
Popoff, изначальный вопрос был вообще ни о чем
Спор был о том, что лучше:
- писать код под конкретные нужды клиента, или
- настраивать "универсальный" код, написанный ранее под другого клиента.
Я считаю, что лучше первый вариант, потому что:
- профессиональные навыки растут, и качество кода "сегодня" заведомо лучше вчерашнего, первый подход предполагает всегда "свежую" версию (большинство архитектурных недостатков Windows связаны с необходимостью поддержки обратной совместимости изначально убогой системы DOS);
- коллекция множества разных модулей заведомо не хуже наличию одного большого, собранного по историческим причинам вместе;
- меньше = лучше, с точки зрения качества решения конкретной задачи.
Спор был о том, что лучше:
- писать код под конкретные нужды клиента, или
- настраивать "универсальный" код, написанный ранее под другого клиента.
Я считаю, что лучше первый вариант, потому что:
- профессиональные навыки растут, и качество кода "сегодня" заведомо лучше вчерашнего, первый подход предполагает всегда "свежую" версию (большинство архитектурных недостатков Windows связаны с необходимостью поддержки обратной совместимости изначально убогой системы DOS);
- коллекция множества разных модулей заведомо не хуже наличию одного большого, собранного по историческим причинам вместе;
- меньше = лучше, с точки зрения качества решения конкретной задачи.
Popoff
popoff.donetsk.ua
Алексей Пешков
мне казалось, что мы уже выяснили, вокруг чего был спор. спор был вокруг того, что я и ONK и, соответственно Вы, по-разному понимаем слово "универсальность". при ближайшем рассмотрении оказывается, что наши подходы мало чем отличаются. отличаются слова, которыми мы называем результат. сам же результат - по сути такой же.
мне казалось, что мы уже выяснили, вокруг чего был спор. спор был вокруг того, что я и ONK и, соответственно Вы, по-разному понимаем слово "универсальность". при ближайшем рассмотрении оказывается, что наши подходы мало чем отличаются. отличаются слова, которыми мы называем результат. сам же результат - по сути такой же.
zk
Новичок
Пример:
Есть некая организация. Структура организации представляет древовидную структуру. И в каждом подразделении работают люди.
Надо написать CMS для сайта такой организации.
Причём хотелось бы чтобы ссылки были "красивые", т.е.
/org/podrazd_a/podrazd_b/.../podrazd_z/ - Так выглядит ссылка на страничку подразделения,
/org/podrazd_x/podrazd_y/.../podrazd_z/news/ - Так выглядит ссылка на все новости подразделения,
/org/podrazd_x/podrazd_y/.../podrazd_z/news/2006/01/10/14:35 - так выглядит ссылка на конкретную новость,
то есть в общем случае:
/org/podrazd_x/podrazd_y/.../podrazd_z/НАЗВАНИЕ_МОДУЛЯ/НАСТРОЙКИ/МОДУЛЯ.
Но при этом ещё должны быть странички людей, причём модули для них те-же:
/org/podrazd_x/podrazd_y/.../podrazd_z/people/ФИО_человека/НАЗВАНИЕ_МОДУЛЯ/НАСТРОЙКИ/МОДУЛЯ
Ну понятно что все директории виртуальные, и структура хранится в табличке, и люди привязаны к структуре.
Возникают следующие проблемы:
1. Проверка вхождения подразделения в вышестоящую структуру, то есть надо прослеживать всю цепочку вышестоящих подразделений, эа задача довольно трудоёмка, т.к. ф-я обхода дерева рекурсивна.
2. Получается "некрасивая" структура ссылки в том плане, что после структурного подразделения обычно стоит название модуля, а в случае страниц людей, это уже будет не совсем модуль. Или может надо оформить его как модуль, и из него уже подключать другие модули?
3. В случае с информацией о подразделении, логичнее будет дать доступ на изменение страниц начальнику подразделения, или же делать отдельный аккаунт для этих целей? Про каскадную систему прав тоже можно подумать, только нужно ли оно...
В принципе думаю что пример достаточно стандартен. Хочу послушать мнения.
Есть некая организация. Структура организации представляет древовидную структуру. И в каждом подразделении работают люди.
Надо написать CMS для сайта такой организации.
Причём хотелось бы чтобы ссылки были "красивые", т.е.
/org/podrazd_a/podrazd_b/.../podrazd_z/ - Так выглядит ссылка на страничку подразделения,
/org/podrazd_x/podrazd_y/.../podrazd_z/news/ - Так выглядит ссылка на все новости подразделения,
/org/podrazd_x/podrazd_y/.../podrazd_z/news/2006/01/10/14:35 - так выглядит ссылка на конкретную новость,
то есть в общем случае:
/org/podrazd_x/podrazd_y/.../podrazd_z/НАЗВАНИЕ_МОДУЛЯ/НАСТРОЙКИ/МОДУЛЯ.
Но при этом ещё должны быть странички людей, причём модули для них те-же:
/org/podrazd_x/podrazd_y/.../podrazd_z/people/ФИО_человека/НАЗВАНИЕ_МОДУЛЯ/НАСТРОЙКИ/МОДУЛЯ
Ну понятно что все директории виртуальные, и структура хранится в табличке, и люди привязаны к структуре.
Возникают следующие проблемы:
1. Проверка вхождения подразделения в вышестоящую структуру, то есть надо прослеживать всю цепочку вышестоящих подразделений, эа задача довольно трудоёмка, т.к. ф-я обхода дерева рекурсивна.
2. Получается "некрасивая" структура ссылки в том плане, что после структурного подразделения обычно стоит название модуля, а в случае страниц людей, это уже будет не совсем модуль. Или может надо оформить его как модуль, и из него уже подключать другие модули?
3. В случае с информацией о подразделении, логичнее будет дать доступ на изменение страниц начальнику подразделения, или же делать отдельный аккаунт для этих целей? Про каскадную систему прав тоже можно подумать, только нужно ли оно...
В принципе думаю что пример достаточно стандартен. Хочу послушать мнения.
Angel Echo
Guest
А почему обязательно хранить структуру сайта в БД и при каждом перемещении узлов выполнять огромное количество операций??? Я храню структуру в XML типа
<PAGE id="20" name="Главная страницы">
<PAGE id="3" name="Раздел">
<PAGE id="7" name="Подраздел">
...
</PAGE>
</PAGE>
</PAGE>
Каждому узлу PAGE соответствует запись в БД с соответствующим идентификатором, где хранится содержимое страницы.
Таким образом все операции со структурой выполняются в одном XML-документе средствами DOM XML и не требуют более 1 SQL-запроса для обновления.
<PAGE id="20" name="Главная страницы">
<PAGE id="3" name="Раздел">
<PAGE id="7" name="Подраздел">
...
</PAGE>
</PAGE>
</PAGE>
Каждому узлу PAGE соответствует запись в БД с соответствующим идентификатором, где хранится содержимое страницы.
Таким образом все операции со структурой выполняются в одном XML-документе средствами DOM XML и не требуют более 1 SQL-запроса для обновления.
Angel Echo
Guest
Дело не только в перемещении узлов. Как насчет получить всех предков какого-либо узла или вывести полный путь к узлу. SQL рекурсивных запросов не поддерживает, а XPath сделает это легко и быстро !
Angel Echo
Guest
Интересно взглянуть на такую функцию и посчитать сколько SQL-запросов она таким образом выполняет. Но почему все сразу принимают в штыки XML? Ведь удобство налицо без написания лишних процедур и функций!
Что касается спора о том, что лучше: писать код под конкретные нужды клиента или писать "универсальный" код.
Ответ дает сама практика. До сих пор не существует универсальных и массово популярных CMS по аналогии с другими видами ПО. Например, созданы используемые подавляющим большинством пользователей текстовые редакторы, программы обработки изображений, мультимедиа проигрыватели и проч. Систем же CMS существует чуть ли не столько же сколько web-студий, а то и больше.
Вывод можно сделать один каждому клиенту - индивидуальный подход.
zk
Новичок
1. XML конечно удобно, но когда всё хранится в БД, создавать отдельные структуры и способы хранения данных под структуру сайта - как то не с руки.
2. Рекурсивная хранимая процедура будет запросов может выполнять и не мало, но работать достаточно быстро. Я думаю что в случае XML, функция тоже реализована рекурсивна, и по скорости работы тут вопрос неочевиден.
Код движка можно написать в достаточно полной мере универсальным, некоторые модули тоже. А то что требуеться конкретно данному заказчику можно добавлять в виде оригинальных модулей.
Только вот тут надо определиться с формулировками того, что есть движок и что есть модуль.
А CMS существует столько же сколько и студий, т.к. веб программистам проще написать что-то своё, в чём они будут хорошо разбираться, возможно причина тут в плохо развитом API СMS, или плохой унификации, вобщем мне сложно рассуждать на эту тему, т.к. этим вопросом я владею не очень хорошо.
2. Рекурсивная хранимая процедура будет запросов может выполнять и не мало, но работать достаточно быстро. Я думаю что в случае XML, функция тоже реализована рекурсивна, и по скорости работы тут вопрос неочевиден.
Код движка можно написать в достаточно полной мере универсальным, некоторые модули тоже. А то что требуеться конкретно данному заказчику можно добавлять в виде оригинальных модулей.
Только вот тут надо определиться с формулировками того, что есть движок и что есть модуль.
А CMS существует столько же сколько и студий, т.к. веб программистам проще написать что-то своё, в чём они будут хорошо разбираться, возможно причина тут в плохо развитом API СMS, или плохой унификации, вобщем мне сложно рассуждать на эту тему, т.к. этим вопросом я владею не очень хорошо.
Saturn
Новичок
мда... спор получился мощный!
очень много интересного и полезного прочитал.
Popoff
ONK
спасибо за ваш спор!
мой ответ на вопрос топика:
то, что удобнее вам, так и делайте.
раз с ООП не умеете, делайте на функциях.
про ядро CMS, над которой работаю, не скажу (очень уж понятие "ядро" в данном случае расплывчатое...), но в общем используется и функциональный и объектный подходы... смотря что где удобнее.
кстати, моё мнение: самое важное в CMS - это УДОБСТВО для пользователя этой CMS!
очень много интересного и полезного прочитал.
Popoff
ONK
спасибо за ваш спор!
мой ответ на вопрос топика:
то, что удобнее вам, так и делайте.
раз с ООП не умеете, делайте на функциях.
про ядро CMS, над которой работаю, не скажу (очень уж понятие "ядро" в данном случае расплывчатое...), но в общем используется и функциональный и объектный подходы... смотря что где удобнее.
кстати, моё мнение: самое важное в CMS - это УДОБСТВО для пользователя этой CMS!