Как верно организовать роутинг для блога?

Question

[Relike]

Как наиболее удачно организовать блог на CodeIgniter (в принципе и на остальных фреймворках)? Конечно желательно не гадить в урл словами типа "/post/", "/article/", "/category/" и т.д. Есть ли какие идеи? Структура может быть следующей: /категория/пост/, /категория/(номер страницы) , /категория/подкатегория/пост/ , /категория/подкатегория/(номер страницы) . Допустим так. Есть ли какие удачные решения?

Из наработок: как-то давным-давно решал подобную задачу таким образом

function index()
	{
		$s1 = $this->uri->segment(1, FALSE);
		$s2 = $this->uri->segment(2, FALSE);
		$s3 = $this->uri->segment(3, FALSE);
		$s4 = $this->uri->segment(4, FALSE);
		if($s1 && !$s2 && !$s3 && !$s4)
		{
			$this->main_cat($s1);
			
		}
		elseif($s1 && $s2 == 'page' && intval($s3))
		{
			
			$this->main_cat($s1, intval($s3));
		}
		elseif($s1 && $this->m_categories->isCategoryUrl($s2) && $this->m_posts->isPostUrl($s3))
		{
			
			$this->post($s3, $s1, $s2);
		}
		elseif($s1 && $this->m_categories->isCategoryUrl($s2))
		{
			if($s3 == 'page' && intval($s4))
			{
			
				$this->subcat($s2, intval($s4), $s1);
			}
			elseif($s3)
			{
				show_404();
			}
			else
			{
				$this->subcat($s2, 0, $s1);
			}
		}
		elseif($s1 && $this->m_posts->isPostUrl($s2))
		{			
			$this->post($s2, $s1);
		}
		else
		{
			show_404();
		}
	}

Answer 1

[dmitriy]

//config/routes.php
$route[':any/(:any)/(\d+)'] = "startup/subcategory/$1/$2";
$route[':any/(:any)/(:any)'] = "startup/subcategory_post/$1/$2";

$route['(:any)/(\d+)'] = "startup/category/$1/$2";
$route[':any/(:any)'] = "startup/category_post/$1";

//controllers/startup.php
class Startup extends CI_Controller{

    public function category_post($post)
    {
        echo 'category_post '.$post;
    }
    
    public function category($cat,$page)
    {
        echo 'category '.$cat.' '.$page;
    }
    public function subcategory_post($subcat,$post)
    {
        echo 'subcategory_post '.$subcat.' '.$post;
    }      
    public function subcategory($cat,$page)
    {
        echo 'subcategory '.$cat.' '.$page;
    }
}

Comments

[Alexander M]

Немного не понял про $route[':any/(:any)/(\d+)']... это не тоже что $route[':any/(:any)/(:num)']... ? Или другой эффект достигается? Спасибо!

[Relike]

Alexander M: Может быть и то-же самое, просто регулярку было быстрее написать)

[Alexander M]

Заглянул под капот. https://github.com/bcit-ci/CodeIgniter/blob/develo... Вот как он видит :num ([0-9]+). Хотя и (\d+) тоже самое?

Answer 2

[index0h]

Oh, not this shit again!

Не пиши свой велосипед, он в любом случае будет хуже остальных.

Посмотри роутер silex, lumen, laravel, symphonye, или любого другого известного фреймворка.

З.Ы. CodeIgniter - это прошлое, забудь его.

Comments

[Relike]

С чего ты решил что это прошлое? Назови мне какой-нибудь весомый недостаток.

[Relike]

Сергей: а ты не думаешь, что возможно это будет плюсом Игнитера. То что он не такой, как все остальные. Он в разы гибче, более расширяемый. В конце концов он интересен как разработчику. Возможно я еще не опытен и поэтому мне нравится писать всё самому, но при всём этом создание сайта на CI на много быстрее создания сайта на том-же Yii.

[Relike]

И сам сайт в разы быстрее работает.

[index0h]

Недостатки:
- нет поддержки PSR
- поддержка говна мамонта (5.2.4) ... php 5.3 официально не поддерживается, о чем можно говорить?
- кастомный автолоад, ну это конечно здорово, но уже как бы давно composer придуман и все такое))
- фреймворк как именно часть приложения. Сама идея на момент создания - была вполне торт, но сейчас это не актуально. CI предполагает следующее: если в самом CI что то работает не так, как нужно - правим CI, следственно официальная дока для проекта уже будет не корректной. Пример: у вас есть средний проект на CI, обросший некоторыми изменениями, новый сотрудник работавший с CI раньше должен будет все равно изучить в полной мере, что вы там поменяли, потому как оф. документация уже не будет подходить. Это путь в никуда.
- глобальные переменные...
- правила валидации моделей пишутся руками.
- что на счет именованных параметров в запросах?
- SOA не возможен

Поймите правильно, я тоже когда-то фанател от CI (лет 6-7 назад), но потом познакомился с другими фреймворками и могу сказать следующее: CI любит куча народу потому, что он очень простой, а простой он потому, что предлагает простые решения "в лоб".
В средних и больших проектах решения "в лоб" обычно не приемлемы.

Сергей > но может еще покажет класс в будущем..
Пока не:
- откажется от 5.2
- перейдет на общие стандарты
- откажется от идеологии "фреймворк - можно изменять"
- победит уже существующие микро фреймворки
он так и останется старой какой мамонта.

Relike > С чего ты решил что это прошлое?
Пункты выше

> Он в разы гибче, более расширяемый.
Что на счет silex?
Расширяемость за счет того, что можно поправить код фреймворка - это не расширяемость - пример хреновой архитектуры.

> Возможно я еще не опытен и поэтому мне нравится писать всё самому, но при всём этом создание сайта на CI на много быстрее создания сайта на том-же Yii.
habrahabr.ru/post/39300 Когда вырастите с проектов, рассчитанных на одного программиста, это пройдет))

> И сам сайт в разы быстрее работает.
Скорость за счет функциональности - не самая хорошая идея. Если хочешь реальной скорости - смотри в строну Phalcone, или HHVM например.

[Relike]

index0h: habrahabr.ru/post/254603 будь в курсе событий
Фолькон - анонизм
Не переписывать код фреймворка, а расширять его, ведь Yii тоже даёт такую возможность, не так-ли?
То что не написано, можно написать самому, либо воспользоваться готовыми решениями.

P.S. Вопрос ставился не так "Скажите, CI говно?", а Как верно реализовать роутинг. И я думаю надо придерживаться этого ибо это уже флуд.

[Relike]

index0h:
- глобальные переменные... ГДЕ?
- правила валидации моделей пишутся руками. Ну я думаю другими местами писать не очень удобно.
- что на счет именованных параметров в запросах? Вы про URI-segment? Пожалуйста не пользуйтесь, принимайте всё как аргументы к методам как во всеми любимом Yii

[index0h]

@Relike
> будь в курсе событий
Да я в курсе, что 3-ий вышел. Даже в PDO смогли, молодцы, что тут скажешь

> Не переписывать код фреймворка, а расширять его, ведь Yii тоже даёт такую возможность, не так-ли?
Yii-way предполагает, что фреймворк отдельно - ваш код отдельно.

> И я думаю надо придерживаться этого ибо это уже флуд.
На счет ЧПУ: тут все зависит от бизнес задач и прошаренности SEO. Для статей норм решением считается slug названия статьи через дефис + id статьи там же, например:
mysite.com/some-very-cool-article-125
Пример кода, что вы сбросили реально гуано. Дело тут в том, что ваш роутер будет понимать всего один человек в мире. Пример, что написал diamond - вполне ок.

> глобальные переменные... ГДЕ?
конфиги, супер глобальные переменные.
> правила валидации моделей пишутся руками. Ну я думаю другими местами писать не очень удобно.
У того же Yii они пишутся как списки параметризируемых валидаторов, у Doctrine - как аннотации, yaml-ы, или php-шные массивы настроенных валидаторов. "руками" === "свой велосипед"

> что на счет именованных параметров в запросах?
Тут не уточнил, в БД. В оф. справке рекомендуется использовать плейсхолдеры "?", для большого количества плейсхолдеров - это не самая лучшая идея.

При чем тут Yii?)) Это не единственный фреймворк, а первая версия вовнутри - полное гуано. Вторая уже по лучше, но за счет завязки на синглтоне для крупных проектов - не подходит.

[index0h]

Чуть не забыл, "CI говно" - вы первым это сказали))

[index0h]

Мысль на подумать: о какой скорости имеет смысл говорить у state-less языка?))

[Виталий Камелин]

index0h

З.Ы. CodeIgniter - это прошлое, забудь его.

docs.phalconphp.com/ru/latest/reference/benchmark/...

[index0h]

Когда нужна реальная скорость - это не php)). Тот же файлькон такой быстрый потому, что не native php. Еще раз. php - state-less язык, только за счет этого говорить о сверх производительности - это по меньшей мере смешно. На каждый запрос создается отдельный процесс, все окружение поднимается заново.

На счет тестов - это с включенным OPcache? Тот же yii используется через yiilite.php? Что на счет кэширования в memcached?

По хорошему - для тех же статических страниц вполне норм решение - заливать в memcached и читать ngnix-ом на прямую. Для остального - хотите выжать из php максимум:
- отказывайтесь от php в сторону HHVM
- отказывайтесь от серверного рендеринга в пользу SPA, или гибридного (как на пример catberry)
- отказывайтесь от максимального числа запросов к БД, кэшироваться должно практически все

PHP - это язык быстрых решений, но не язык быстрых систем.

[Relike]

index0h: CI устраивает по скорости работы, понятно что Phalcon его делает на порядок. Ключевой момент в работе с базой данных. С ней нативный код тоже быстрее работает? Я думаю что нет, т.к. запрос выполняется на стороне базы данных. И смысл использовать гом**ятину (модуль для веб сервера оО) взамен легкого и ПРОСТОГО фреймворка?

[index0h]

Месседж был в следующем:
если нужна скорость выполнения - это не CI
если нужна функциональность - это не CI
если проект большой - это не CI
если нужно что-то "на коленке" - вот это CI, но есть решения по лучше

[index0h]

Relike
Простой - это вовсе не значит, что быстрый, правильный, или удобный. Это значит решения "в лоб", они же чаще всего - не самый хороший выбор.

[Relike]

index0h: CI не быстрый? Быстрый. CI не правильный? В правильных руках, которые не лезут в системные файлы - правильный. CI не удобный? Как по мне по сравнению с Yii - бизнес-класс против эконома. И это лично моё мнение. (Yii - потому-что за другие говорить не могу).

Я думаю тут каждый человек выбирает инструмент который ему лично ближе. Есть люди которые "прАграммисты под Wordpress". Есть поклонники Joomla (o_O). Их-же что-то держит на этих системах и они готовы глотки рвать, но отстаивать свою правоту не обосновав ничем весомым своё решение. Так-что я думаю не стоит им уподобляться... Я люблю игнитер..я использую его по профессии как обязательное требование и следовательно что-бы небыло разноп**дицы у меня в голове я его использую и в обыденной жизни.

Да и вопрос ставился чутка иначе :)

[index0h]

@Relike

Так как вы сказали что знакомы с Yii буду приводить сравнение с ним.

0. Autoloading
www.codeigniter.com/user_guide/general/models.html
ci: $this->load->model('modelName') - НЕ ОК, но справка так рекомендует!
> If you find that you need a particular model globally throughout your application, you can tell CodeIgniter to auto-load it during system initialization.
ЛОЛШТО?? Автолодинг на нейспейсах еще в 5.3 появился. А то, что предлагается подгружать модели в конфиге при инициализации - за это надо... плохо в общем сделать.

1. Роутинг + Контроллеры
www.codeigniter.com/user_guide/general/routing.html
https://github.com/yiisoft/yii2/blob/master/docs/g...

У ci - значения параметров запроса жестко привязаны к их порядку объявления, у yii они привязаны к именам. Контроллер ничего не должен знать о роутинге, он решает другие задачи.
Наличие _remap - это вообще зло))

2. View
www.codeigniter.com/user_guide/general/views.html#...
https://github.com/yiisoft/yii2/blob/master/docs/g...

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

3. Модели
www.codeigniter.com/user_guide/general/models.html
https://github.com/yiisoft/yii2/blob/master/docs/g...

Модель не должна быть связана с пользовательским вводом, это задача контроллера, но справка ci учит обратному! Если вы поменяли ЧПУ - придется исправлять все зависимые контроллеры И все зависимые от них модели, это путь в никуда.

Что на счет валидации данных?
В ci это дело должно быть прописано обязательно руками отдельно. Но на секундочку, проверка данных перед запросом к БД - это одна из важнейших задач модели.
Я в курсе про form_validation, валидация форм - это проверка пользовательского ввода, валидация модели - это работа с БД, если в промежутке между form_validation и моделью данные изменяются - их обязательно необходимо проверять.

4. Контроль доступа, ci его просто нет из коробки, у yii - есть причем несколько имплементаций.

5. Кэширование, что на счет инвалидации кэша?
У yii есть зависимости, у ci - только ручное удаление. Кэша фрагментов тоже не вижу, хотя это ончеь удобно))

6. Виджетов тоже не наблюдаю..

И это только беглый просмотр доки))

> CI не быстрый? Быстрый.
Быстрый он не потому что качественный, а потому что убогий по функционалу. Качественный фреймворк - это тот, в котором составляющие части являются минимально зависимыми друг от друга, что бы в случае изменений - правки приходилось выполнять в минимуме компонент.

> ... но отстаивать свою правоту не обосновав ничем весомым своё решение. Так-что я думаю не стоит им уподобляться...

Вы считаете мою критику не обоснованной?))

> Да и вопрос ставился чутка иначе :)
На ваш вопрос ответили уже выше)

[Relike]

index0h: Да, я считаю вашу критику не обоснованной. Вы выделяете то, что в современных фреймворках "много что уже есть". Ок, давайте использовать Битрикс, там всё есть, аж на целый гигабайт текстовых файлов) !

[index0h]

> Да, я считаю вашу критику не обоснованной.
Да мне в общем то все равно, вы же защищаете подобие фреймворка, разработчики которого даже в MVC не смогли))