Закончу спор: CMS - это движок с графическим интерфейсом для пользолваелей. То есть: 1. Сначало было Ничего. 2. Потом появился движок. 3. Потом разработали и прикрутили интерфейс. 4. И назвали эту хрень CMS-ом. Возможен такой вариант: Сзествует движок (к примеру какой-нить демон) которому нафиг не нужны никакие интерфейсы администрирования, тогда наверное это да тогда это ничего общего с CMS А иначе хоть назовите себя пупами земли но вы делаете либо общие либо частные случаи CMS, разница лишь в том, что частные случаи делать ПРОЩЕ чем общие. vb
Я пишу подобный движек, но для себя, точнее сказать для фирмы в которой я работаю. Движек можно будет использовтаь во всех моих работах написанных ранее, он будет самообучатся (посредством моих рук). Также как и в других подобных, будет использована модульная система. Ну и конечно будет то, что нет в других движках (да сообственно как и у меня не будет чего-то от других). Но я приложу все усилия, чтобы сделать лучше чем подобные. ЗЫ: К сожелению работаю один, потому что НИКОМУ не доверяю 8)
Ну в общем пока что открыто обсуждать свои (и чужие) разработки готов только Горбунов Олег, я и возможно Петр. Не густо... ZZZubec это здорово и даже замечательно, но готов ли ты свою разработку, в каком бы состоянии она ни находилась, выложить на публичное обозрение и изучение? Тема-то для этого создана была.
я непротив открытого исходного кода, но за этот код (хотя он и мой) меня моя фирма просто присобачит (т.к. проект будет комерческим). Я могу с легкостью делится решениями или алгоритмами по данному сабжу, но выложить несмогу, сорри. ЗЫ: Если есть возможность, то могу присоеденится к любому opensource проекту (как одиночка), писать скрипты для него или классы совершенно бесплатно (и не использовать их в смоем проекте). Главное в этом деле идея, если идея мне по душе, то почему бы не помочь - тем более что в последствии народ будет знать своих авторов по именно.
Подготовлю свой код - выложу. Просто у меня нету его в чистом виде - под каждый проэкт подгоняеться, добавляються нужные методы, убираю ненужные
а вот это зло ибо на одном проекте реализовано одно, на другом другое, на третьем - третее. и тут нужно поднимать ещё один и начинаешь бегать по проектам - собирать что там нареализовано... нужен репозиторий, хранящий актуальную версию движка!
dark-demon Ну ядро то едино, просто в каждом проэкте есть свои специфические требования, которые я запихиваю в ядро, т.к. они используються везде. Вот соберу это ядрышко - выложу. Да и форма моей работы позволяет так делать, ибо в любом случае времени больше уходит на продумывание, чем на реализацию - с маленькими сайтами дело просто не имею, и не получаеться иметь - вечно что-то большое стругаю
Некоторые мысли по поводу сабжа: 1. URI должен однозначно указывать на view или controller. например, URI: http://site.ru/forum/topic/4821/2/?dynamic=parametr идентификатор view будет таким: /forum/topic плюс, ему передаются параметры: 2; dynamic=>parametr 2. view и controller должены знать свои URI. это необходимо для формирования ссылок - в темплейтах не должно быть никаких ссылок. только идентификатор view или controller и дополнительные параметры. 3. URI должен быть максимально коротким, чтобы его было удобно вводить руками. то есть: /topic/global-faq/ а не: /forum/about/faqs/topic/global в крайнем случае: /forum/topic/global-faq/ 4. каждый view должен выводить один и тот же тип данных. параметры должны определять лишь какие именно. например, /topic/2 (выводящий топик номер 2) и /topic/edit/2 (выводящий форму редактирования топика) - должны быть разными view. (при отделении идентификатора от параметров используется "жадный" алгоритм) 5. содержание выводимых view данных не должно зависеть от POST данных. для обработки POST запросов используется controller висящий на другом URI, который ничего не возвращает (разве что код ошибки), а редиректит на подходящий view. например, /topic/edit/2 отсылает при сабмите данные в /topic/edit/post который редиректит (http-redirect, а не "вы будете перенаправлены через несколько секунд") на /topic/edit/2 или на /topic/2 в зависимости от ситуации. такая схема исключает возможность случайного повторного сабмита и позволяет свободно обновлять полученную страницу с помощью f5.
dark-demon Полностью согласен с пунктами 3 и 5. Насчет пункта 5: надо добавить, что это поможет от рефреша страницы, но не поможет от случайного двойного клика в момент отправки. Тут нужно придумывать что-то другое. Пункты 1, 2 и 4 выглядят немного подозрительно в плане того, что от них попахивает паттернами проектирования... но я лучше подожду когда кто-нибудь еще выскажется
Dagdamor, да, в некоторой степени это паттерны, которые на мой взгляд упрощают динамическую разработку. 6. view должен состоять из двух частей: 6.1. генератора данных на основе модели и других view (PHP). 6.2. вывод полученных данных (темплейты)
dark-demon 6.3. файла конфигурации (чтоб при правке данных о паролях к БД не нужно было искать в коде где-то править)
Все пишут что должен делать framework. ИМХО, он не должен задавать способ - конфигурирования - отображения - генерации/разгребания URL - Backend'a контента ... Фреймвек предлагает варианты - вы выбираете оптимальный.
Ti, речь не о фреймворке, а об организации движка. Vladson, плохой пример. для работы с бд лучше использовать синглетоны. соответствено все пароли храним у них в коде инициализации. кроме того, вовсе не обязательно разделять на файлы - можно разбить один файл на логические части: конфигурация, генерация данных, вывод.
vb, а если нечто имеет графический интерфейс для пользователя, но этот интерфейс не управляет отображаемыми данными, а управляет например модулями, конфигурационными переменными, логикой поведения сложных компонентов,,, а среднестатистический пользователь будет на это очень долго и удивлённо смотреть без особых результатов. Как называется такое по твоему классификатору? -) dark-demon, всё написанное спорная демагогия 1. Всё что он должен, так это чтобы данные запроса дошли до конкретного модуля, а способ их передачи в запросе не имеет значения. 2. Представление может знать а может не знать, как вызывается контроллер для которого оно создано. 3. Кто-ж его будет руками вводить? Да пусть он будет каким угодно, лиш-бы поисковыми машинами индексировался нормально, а пользователю всё равно, главное чтобы кнопка была красивой. -) 4. Ниасили глубину мысли Наверно имелось в виду, что каждому представлению нужен собственный и единственный контроллер? Ну да, а как иначе то? Можно ещё написать, произведение двух двоек равно двойной их сумме. 5. Спорная мысль, есть места где это нужно, есть где нет. Я сейчас использую и то и другое, при этом в интерфейсах администрирования я редиректированием вообще не пользуюсь. От повторных операций надёжно защищает одноразовый идентификатор действия, фактически я использую перенаправления после приёма пост данных только там где этого диктуется логикой приложения. Вобщем, если охота поспорить, то придраться можно к любому слову.
движок, ядро, фреймвек, cmf, это вещи, при помощи которых можно при минимальных усилиях создать сайт любой структуры, любого назначения, любой сложности. Я не разделяю их. Если у вас это разные вещи, читайте "движок" вместо "фреймвек"
имеет. короткий чпу лучше, чем нагромождение амперсандов, вопросиков и знаков равенства. кроме того, не должно быть лишних связей между view. конкретный URI должен вызывать конкретный view, а не так, что один view перекинул на другой, другой - на третий и тп. view должен целиком и полностью определять что будет выведено браузеру и зависеть это должно только от параметров, с которыми он вызывается. соответственно нужен однозначный алгоритм преобразования URI во входные параметры, но, это должен быть такой алгоритм, что параметры не должны зависеть от того куда мы поместим view. например, перенос /phorum/topic в /ru/phorum/topic не должен никак сказаться на работе. оно и не должно знать. ссылку на контроллер формирует сам контроллер. представление лишь обращается к нему с запросом "дай мне ссылку на себя". да кто угодно, кто является постоянным посетителем. зачем ему пробираться через три уровня иерархии, если можно просто дописать несколько буков вконце адреса? безусловно, ссылки вида /index.php?razdel=4&podrazdel=18 никто руками вводить не будет. видимо у нас разные представления о контроллере. а чтобы осилить глубину - достаточно вникнуть в пример. особых причин неиспользовать этот метод я не вижу. зато я вижу причину использовать - не нужно заботиться о поддержании актуальности данных. например, какой-то модуль получил данные из таблицы, потом контроллер изменил в них данные, потом всё это вывелось и пользователь видит устаревшие данные. приведу другой пример: контроллер изменил какие-то данные, но на результат вывода они не влияют. тогда зачем посылать пользователю всю страницу, если можно перенаправить на правильный урл и браузер возьмёт страницу из кэша. На крайняк пошлёт запрос "а не изменились ли данные", и получит ответ "не изменились". В общем совмещение POSTа и GETа. добавляет нам разных трудностей, но совершенно не даёт никаких преимуществ. пример реализации? топик ведь не для этого создавался... в общем, если ты видишь какие-то неудобства в следовании этим правилам - пожалуйста напиши, иначе толку этого спора нет. Ti, а вот я - разделяю. cmf - это среда удобная для программиста и позволяющая без многочисленных копипастов писать модули, с какой бы cms ему не пришлось работать. cms же решает другую задачу, а именно "как упростить процесс управления данными", в частности, чтобы не пришлось каждый раз копаться в коде, чтобы произвести типовую операцию. так вот, сила cms во взаимной интеграции модулей, а чтобы они могли продуктивно друг с другом работать нужен некоторый апи, который, да, несколько ограничивает свободу. вопрос лишь в том, насколько узки его рамки.
Ммм... а что тогда должен вообще делать фреймворк? Самых важных функций вы его лишили, да еще и таинственное многоточие в конце если фреймворк вообще ничего не умеет - кому он нужен?
Фреймвек - Швейцарский нож. Сам по себе он ничего не умеет, это удобный инструмент, конструктор если хотите. Я его не лишаю функций, я лишь определяю функции. А вызывать функции уже не фреймвека дело. причем здесь штаны? про cms слов небыло вы мне указали что про фреймвек тут речи не идет я сказал что считаю cmf и framework одним и тем же, а потому мой пост имеет прямое отношение к теме. вы мне начали рассказывать про то какие разные вещи - cmf и cms прежде чем дискуссию разводить предлагаю разобраться в названиях, что мы и как называем, а то непонятки полные.
ONK Не согласен... один из самых удачных проектов Сети - Википедия - удобен именно тем, что адрес можно (и нужно) набирать руками, без шаманства типа "заходим на сайт, ищем форму поиска, вводим строку, ищем нужное среди кучи результатов". Ti Вы не забывайте, как швейцарский нож выглядит. Это устройство с кучей инструментов, каждое из которых жестко заточено под решение конкретной задачи. То же самое с фреймворком - он не должен предлагать расплывчатое решение, которое "для любого дела сгодится, но кое-как" (как кухонный нож скажем), а должен предлагать конкретные и удобные решения, пусть и ограничивающие свободу разработчика.
да, это так, и отверток там несколько штук, и нож не один. для конфигурирования сегодня ini файл, завтра xml, послезавтра DB... для backend-а контента сегодня db_mysql, завтра xml, послезавтра файлы, а в будущем нейро-сеть со своим протоколом при использовании фреймвека, я указываю что, как и откуда - не хватает модуля для связи с марсианинами - дописываю фреймвек
Ti Ну хорошо, а где все эти вкусности должны находиться? Если они часть фреймворка - то согласен. А если каждый их пишет для себя сам - тогда нет, ибо опять возникает вопрос, кому нужен такой паровоз, который перед использованием нужно доводить напильником. Ведь все перечисленные тобой вещи присутствуют на любом сайте, а значит их имеет смысл выносить в движок, чтобы разработчикам не приходилось один и тот же велосипед собирать каждый раз заново.
Dagdamor конечно в движке. я лишь заметил, что движок не определяет используемые инструменты, он их предлагает
Ti, под cms я подразумеваю упомянутый тобой "движок". а что на базе cms делается - называется сайт (или портал). итого в моей иерархии четыре ступени: 1. raw php - просто код на пхп. 2. framework (cmf) - унифицированные блоки кода упрощающие процесс написания движка. 3. engine (cms) - работающий комплекс с ядром и подключаемыми модулями и богатыми или не очень возможностями настройки. универсальная заготовка для сайта. 4. site - работающий комплекс с ядром, определённым набором модулей подключенных в определённые места, выглядящих определённым образом. конкретный готовый продукт.