MaxSite CMS и CodeIgniter
Пятница, 4 сентября 2009 г.
Просмотров: 2249
Подписаться на комментарии по RSS
В последнее время почему-то активизировалась тема о том, что якобы 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-приложения.



Комментариев: 8
Отослал бы сразу к http://code-igniter.ru/user_guide/general/routing.html. Кому нужно, поймёт.
очень забавное объяснение. А главное -- раскрывает суть обвинений в сторону движка...
Скорее всего, большинство обвинений в своей основе сводятся к тому, что Вы в своем движке отошли от ООП. Ваш движек просто использует роутинг для запуска своего котроллера и.... и все. Ну еще часть библиотек используются.
Лично для меня -- уход от ООП -- вот главный момент. Но это уже дело вкуса и стиля программирования.
]]>
Еще что-нибудь скажете? Я как раз собираю подобный бред в коллекцию.
Я бы назвал 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.
]]>
Молодец Максим! Честно говоря у меня терпения бы не хватило на "разжёвывание" подобных вопросов. Считаю подобные статьи крайне полезными, не будем забывать о начинающих разработчиках.