MaxSite CMS и CodeIgniter
04-09-2009Время чтения ~ 4 мин.PHP 24126
В последнее время почему-то активизировалась тема о том, что якобы MaxSite CMS идеологически неверно построена. Нужно было делать по туториалу CodeIgniter, а я, подлец, сделал по-другому и теперь, якобы нельзя совместно с MaxSite CMS делать «классические» CodeIgniter-приложения.
Основные претензии сводятся к тому, что в MaxSite CMS используется единый контролер, что не нравится фанатам CodeIgniter, которые не в состоянии продвинуться дальше прочтения хелпов.
Я решил, вместо того чтобы крутить пальцем у виска, объяснить и продемонстрировать использование MaxSite CMS с «классическим» CodeIgniter-приложением.
Но, для начала немного объяснялок.
Устройство CodeIgniter таково, то методы с контролерами определяются из URL вот по такой схеме:
example.com/class/function/id
Контролер - это файл с классом, который ассоциируется с URL. Например
example.com/blog/
Будет вызван файл controllers/blog.php в котором должен быть класс Blog. Если мне нужно вызвать контролер с явно указанным методом, то вызываем так:
example.com/blog/page
То есть контролер/класс Blog, в нем метод page. Еще можно указать прочие параметры, например id:
example.com/blog/page/id
В данном случае id будет передан как параметр метода page.
Это «классическая» схема работы CodeIgniter, где контролеры и их методы имеют жесткую структуру и, соответственно, предопределенный набор URL.
Любой, мало-мальски мыслящий человек понимает, что при таком подходе невозможно задать произвольные URL. Например я хочу, чтобы
example.com/hello
Выводилась страница с короткой ссылкой hello. А также
example.com/contact
Подгружался файл contact.php.
Потом появится другой клиент и скажет, что его не устраивает hello, пусть это будет about, а contact заменить на you_message. Потом появится третий и скажет вообще всё поменять к чёртовой матери и убрать этот contact, как источник спама.
Таким образом уже на этапе разработки необходимо предусмотреть возможнось произвольных методов/контролеров. Именно по этой причине в MaxSite CMS используется _remap(), метод который перекрывает «стандартное» определение методов контролера.
То есть мы можем определить один контролер и в его _remap() получать вызываемый метод. Дальше мы анализируем этот метод и решаем что с ним нужно делать.
Также в CodeIgniter можно задать дефолтный контролер. То есть вместо того, чтобы вызывать
example.com/blog/page/id
Мы можем указать в качестве дефолтного контролера - blog и тогда запросы сократятся до вида:
example.com/page/id
Делается это через роутинг в файле конфигурации routes.php. Для MaxSite CMS указан дефолтный контролер maxsite. Соответственно у нас есть и controllers/maxsite.php. В нем уже используется _remap(), дальше идет инициализация ядра системы и т.д.
Если вы дочитали до этого места и вы все равно не поняли, то вы либо невнимательны, либо не знаете даже азов CodeIgniter. Потому что уже сейчас вы должны сообразить как подключить произвольное CodeIgniter-приложение.
Продемонстрирую.
В комплекте CodeIgniter есть контролер welcome. Соответственно скопируем файл welcome.php в application/controllers и welcome_message.php в application/views. Я понятия не имею (условно) как и что там реализовано, но мне нужно вызвать по адресу example.com «содержимое» welcome.
Идем в routes.php и пишем:
$route['default_controller'] = "welcome";
Обновляем наш example.com и вуаля!, видим «Welcome to CodeIgniter! бла-бла-бла».
Ок, скажете вы, но теперь мы хотим получить доступ к MaxSite CMS! И будете правы, потому что роутер для MaxSite CMS настроен так, что если адрес содержит несколько сегментов, разделенных слэшем «/», то управление передается в контролер maxsite. Вы можете набрать example.com/admin и убедиться, что прекрасно попадает в админку MaxSite CMS.
Видите, изменили одну строчку, и уже какой результат!
Но, если вы делаете свое CodeIgniter-приложение, то скорее всего у вас должен быть другой роутер, например могут быть «blog», «post» и т.д. и всё это отдельные контролеры и их методы. Так что нужно сделать? Правильно, просто переписать условия в роутере!
Например мы хотим получать все запросы на welcome. Делается так:
$route[':any'] = "welcome";
Давайте теперь переиграем задачу. Пусть по умолчанию будет работать MaxSite CMS, а для перехода к welcome будем использовать адрес вида:
example.com/my
Меняем роутер так:
$route['default_controller'] = "maxsite"; $route['my:any'] = "welcome";
Переходим на заданный адрес и замечательно видим, как работает наш уже любимый welcome. При этом у нас также замечательно работает и MaxSite CMS.
Надеюсь, что данный экскурс в routes.php поставит большую и жирную точку на тех, кто утверждает, что в MaxSite CMS нельзя использовать «классические» CodeIgniter-приложения.
Отослал бы сразу к http://code-igniter.ru/user_guide/general/routing.html. Кому нужно, поймёт.
очень забавное объяснение. А главное -- раскрывает суть обвинений в сторону движка...
Скорее всего, большинство обвинений в своей основе сводятся к тому, что Вы в своем движке отошли от ООП. Ваш движек просто использует роутинг для запуска своего котроллера и.... и все. Ну еще часть библиотек используются.
Лично для меня -- уход от ООП -- вот главный момент. Но это уже дело вкуса и стиля программирования.
Еще что-нибудь скажете? Я как раз собираю подобный бред в коллекцию. :coolsmirk:
Я бы назвал MaxSite одной из примочек\плагинов\библиотек, коих полно на официальном ресурсе фраемворка, просто MaxSite базируется как CMS со своей структурой. И никаких правил она в принципе не нарушает. Подключается также как и множество других рюшечек для CI.
@TX: перед автором стояла задача сделать Wordpress подобную систему, но намного лучше. Свою задачу он выполнил.
PS
Нравится новаторская система регистрации, через 1 комментарий =). Нигде такого не встречал, впервые увидел когда поставил mso.
Извините, что не в теме просто отчаялся уже, моя проблема изложена вот здесь: http://mywordpress.ru/support/viewtopic.php?pid=52198
Сайт http://www.blog.khlyupin.ru
Помогите, чем можете!
Хм... Я с автообновлением никогда не работал, но наверное нужно откатить версию WordPress назад, чтобы его обмануть и попробовать еще раз автообновление.
Скорее всего WordPress хранит данные о результатах обновления в своих опциях в БД. Можно попробовать вручную изменить это значение. Так на вскидку это «update_core». Точнее не скажу.
Систему не ставил, но судя по этому посту, ничего страшного при интеграции не должно происходить, так как всё сделанно используюя именно стандартные возможности CI.
Молодец Максим! Честно говоря у меня терпения бы не хватило на "разжёвывание" подобных вопросов. Считаю подобные статьи крайне полезными, не будем забывать о начинающих разработчиках.
уже два часа как я услышал про MaxSite CMS ...
первый час небыло пределов радости, неужели я нашёл под код игнитер CMS-ку как базис под будущие проэкты, которую смогу расширять .... почитал .. полазил в админке и тп ... с точки зрения пользователя - прекрасный текстовый процессор...
второй час это час разачарований ....
сперва наткнулся на эту статью в блоге автора
http://maxsite.org/page/maxsite-cms-and-codeigniter#cut
почитал ... вроде как правильно написано всё, сразу и непонятно к чему придераются и почему кто то где то нападает что maxsite нарушает идеологию CI ... ведь можно использовать рутинг как там и написано ...
и дальше поигравшись как пользователь я полез смотреть в код с профессиональной точки зрения как программист который использует CI как основной фрэймворк вот уже на протяжении 5-6 лет... тут то я пожалуй понял за что упоминались нападки ....
заходя в каталог templates я совершенно не ожидал увидь НЕ темплейты а микс пхп+хтмл в стиле 90х годов ... при чём идеалогия темплейтов искажена абсолютно (а про MVC подход то я вообще молчу - его просто нет)
это полнейший откат к стилю 90х ... вопрос - зачем понадобился CI ? можно использовать пир библиотеки или просто набор функций и писать в стиле 90х смешивая всё в одну кучу ... это к сожалению было полное разочарование
[b]Почему ? вот объективный взгляд:[/b]
1) темплейты это микс хтмл+пхп во всех возможных вариациях - нет единого стиля да и темплэйтами это сложно назвать. почему ? объясню чуть ниже...
1.а) используется альтернативный синтаксис пхп
1.б) используются хтмл тэги через echo ''.$variable.'';
1.в) используется хтмл с просто огромными вставками пхп в котором есть пункт 1.б)
2) есть один офигенно-здоровенный common.php (сорри если ошибся пишу по памяти) в котором намешано абсолютно всё и хтмл тэги по типу 1.б) и функциональный подход и ООП подход и всё в одном файле - просто явные 90е годы
я так думаю что это должно бы было быть моделью раз там сосредоточение и формирование запросов к базе ... но это не модель а всё вместе... просто кусок олд-стайл и бэд-стайл пхп в котором намешано всё до кучи ... :(
3) ну думаю ... может остальные файлы хоть на контроллеры будут похожи ... и снова промах и снова в них намешано всё ...
то есть MVC отсутствует - как сказали бы при СССР - как классовый враг :)
это я могу назвать ни как иначе как откат ко временам Советского Союза в программировании...
теперь возвращаясь к так называемым темплэйтам ... я никого учить нехочу - мы тут все грамотные ... но может вспомните для чего темплэйты создавались ? что бы облегчить жизнь дизайнерам(или веб-мастерам называйте как хотите) и отойти от самого программного кода ... что бы человек имеющий весьма смутное представление о программировании пользуясь простейшими логическими операторами и единым подходом/стилем к данным операторам мог работать с дизайном ... в папке же "templates" понятие темплэйты в классическом понимании этого подхода отсутствует как второй идеологический и классовый враг. как я написал выше там всё намешано и логика и функции и хтмл и всё с разными подходами и даже пару коннектов к базе нашёл ... ну и понятное дело пхп ООП в темплэйтах, пойдите расскажите НЕ программисту про ООП, пусть пользуется :)
ребята, я глубоко уважаю ваши старания и я понимаю сколько вы вложили труда в эту ЦМС НО опять таки мой вопрос заданный выше [b]"а зачем вам CodeIgniter ?"[/b]
ради класса коннекта к базе и паре других классов с хелперами ?
с таким подходом CI ненужен вообще ...
почитайте пожалуйста ещё раз вот тут (первая ссылка по запросу в гугле "зачем нужны фреймворки") http://www.simplecoding.org/kak-sozdat-svoy-site.html
и обратите [b]внимание НА "А фрэймворк кроме того определяет архитектуру приложения."[/b]
к сожалению данная CMS ничего общего с архитектурой CodeIgniter-a и MVC не имеет. это просто готовое решение которое с код-игнитером не должно иметь ничего общего :(
фрэймворки создавались для того что бы объеденить группы единомышленников и задать определённые стандарты в написании кода используя определённую структуру, определённые программные решения, пусть даже весьма расплывчатые (всегда найдётся индус который с радостью во вьюхе напишет функцию, обратится на прямую к базе или напишет кучу пхп ООП кода) НО стандарты (жаль что пхп не питон)... когда другой программист работая с системой будет себя чувствовать почти как дома ...
так что вот так ... такое вот глубокое разачарование меняпостигло ... и это не просто нападка, как мне кажется это вполне аргументированная критика ...
Мда, тянет на целую статью. Аргументация, правда, слега все таки хромает. Во-первых Maxsite все таки работает и может дать сто очков вперед многим другим. Во-вторых, почему Вы решили, что автор ничего своего не должен вкладывать, а слепо следовать идеологии CI и на шаг от нее не отступать? Собственно потому это Maxsite с использованием CI, а не CIю Ну и в-третьих, если Вы так давно используете CI, у Вас должно быть море своих наработок с ним, зачем Вам понадобился MaxSite?
Ну а по поводу шаблонизации, мда, тут я согласен, надо упрощать, максимально. В общем я так понял, что главные Ваши претензии именно к шаблонизации, но это же можно было короче написать ;)
Максим, в общем не слушайте никого по поводу идеологий CI. Продолжайте развивать СВОЮ CMS, она получается добротной. Но шаблонизацию, я бы тоже попросил упростить, для дизайнеров действительно, чем проще и меньше программного кода, тем он лучше состряпает обертку. Идеально было бы вообще в единственном файле весь HTML код сосредоточить, а для блоков, модулей, виджетов уже и отдельные шаблончики со своим HTMl кодом/ Но это так, пожелание :)
Я признателен вам за столь большой комментарий. :) Отлично понимаю, что CodeIgniter-программист хочет во всем видеть только реализацию по примерам хелпа, но главная притягательность CodeIgniter, как раз и заключается в его гибкости. Если вы потратите еще два часа на изучение MaxSite CMS, то увидите, что система достаточно активно использует CodeIgniter-библиотеки, хелперы да и само «ядро» CodeIgniter. Поэтому ваш вывод относительно нужности CodeIgniter MaxSite CMS ошибочен. Даже если отказаться от CodeIgniter, то нужно будет изобретать/заимствовать аналогичные библиотеки и хелперы. По-моему и ёжику понятно, что мы получим такой же фреймворк, как и CodeIgniter.
А вот, что касается CodeIgniter, то стоит отметить, что он заточен под одиночный сайт (аля-хомяк), где используется строгое именование ссылок, простенькая выборка из базы, шаблон с фиксированной структурой и т.п. Для CMS нужен совершенно другой подход, поэтому в MaxSite CMS и используется собственная архитектура, где CodeIgniter отведена роль, ради которой он, собственно, и создавался: предоставить в распоряжение приложения свои «кирпичики».
удивляюсь над "дэбилами" которые критикуйт этот движок!
тот же вордпресс который родился в 2000-ом нууу оооочень современный работает 10 раз медленнее... лично проверял!!!
Прелесть максайта в том что даже чайники могут им управлять с лёгкостью и самый большой + что на максайте можно учится!!!
критикавать максайт должны его пользовотели, а таких я не видел и никак не пойму как могут такие "продвинуте" программист критикавать движок!
для меня самое главное в максаете:
1. Скорость офигенная!!! даже на самом дешёвом хостинге работает как ферари!!!
2. Очень простой! можно использовать и учится на нём одновременно!
3. И самое главное то что на нём можно сделать великолепный блог/сайт и зарабатывать деньги!!! вот и всё...
Максайт будет одним из лучших движков в будущем! (имхо)
п.с. сори за г.а. :)
Спасибо за статью!