- PHP
- Зроби сам
- Apache
- посилання
- URL Rewriting
Хочу змінити реалізацію чпу у себе, але не знаю як буде краще. Під спойлером описаний мій спосіб. Хотілося-б подивитися як це реалізуєте ви без використання фреймворків
Тема Це пишемо в файлі index.php після завантаження ядра і всіх необхідних файлів
файл з правилами виглядає так:
Наприклад для test.ru/user/new буде підключений файл modules / account / new_user.php,
для посилання test.ru/user/settings - modules / account / settings.php і в залежності від того які налаштування вказані - вони і будуть виведені (по дефолту general). Правда в такому випадку модуль підключається інакше:
Можна звичайно вантажити файл modules / account / index.php і вже в ньому визначати дії, і так для кожного модуля - незручно, тому вирішив: нехай все буде в одному місці (можна винести в окремий файл).
Файл htaccess виглядає просто
Цей спосіб був написаний давно і цілком нормально працює, і я так давно його використовую що не можу придумати нічого нового.
Єдиним плюсом є те, що можна вказувати будь-які правила, наприклад:
буде відображена сторінка профілю користувача з id = 15484
або просто логін користувача, без зазначення його id
Мінусів кілька. Крім очевидних - не можна передавати параметри через масив $ _GET.
то мені в такому випадку треба писати додаткові правила з урахуванням типу і сортування, виглядати буде приблизно так:
ps: вибачте, якщо щось мутно описано - Липкі вже
URI має вигляд example.com/
де
- це правило, яке описує вибір класу / скрипта / функції, яка буде обробляти параметри
наприклад, / post / add можна перетворити в class PostController
наприклад, / x / 1 / y / 2? z = 3 можна перетворити в асоціативний масив array
Якось схема аж надто складна. У загальному вигляді диспетчеризація здійснюється за коштами регулярок. і все.
Використовувати великі жирні фреймворки теж лішіни сенсу, краще пошукати мікрофреймворкі або окремі бібліотеки для реалізації раутінга.
VBart. при всій моїй глибокій повазі до пітонові, помічаю за багатьма пітоністамі родову травму ненависті до php.
Той URI, який ви привели стандартна річ для тих років і ніяк до япу не прив'язаний. Пітон, який в той час робив перші боязкі шашки в інтернеті, робив їх через те ж саме.
Я за останні десять років ніяких милиць з цього приводу не використовував і серверних рерайта практично ніколи не торкався. Мені здається ви живете в якомусь упередженому ідеологічному тумані.
fear86
Дуже просто, у вас є додаток, і якщо ви пишете для вебу, то швидше за все воно реалізує wsgi-інтерфейс (описаний в PEP-333 [3]). У найпростішому вигляді у вас є функція, т.зв. wsgi-handler, яка в якості параметра приймає масив зі змінними оточення, включаючи URI. Що далі з ним робити і як його парсити вирішувати вам. Немає ніяких скриптів в області видимості веб-сервера і відповідно немає ніякої прив'язки до імені скрипта, або ще чого-небудь. Як будуть виглядає ваші URI - вирішувати тільки вам, і швидше за все ви їх зробите хорошими і простими, просто тому, що такі URI парсити теж легко і зручно.
Але це зовсім такий нульовий випадок. Я його привів тому, що зараз PHP-програмісти мені скажуть, що в їх фреймворками є все те ж саме. Однак таке питання, як обговорюється в топіку, міг задати тільки PHP-програміст, і сам термін ЧПУ теж був придуманий в PHP, просто тому, що перш ніж винаходити способи робити URI красивими і зрозумілим, необхідно спершу було їх зіпсувати.
В реальності швидше за все ви пишіть використовуючи який-небудь фреймворк, який сам за вас робить всю роботу по розбиранню URI і просто далі надає зручний інтерфейс. Якщо це django, то в найпростішому випадку у вас є файл urls.py (або кілька) в якому просто прописується як відображати URI на відповідні функції-обробники (чомусь це навіть можна порівняти з набором location -ів в nginx), виглядає це приблизно так (зліва регулярний вираз із захопленням змінних, а праворуч функція яка буде позвана з відповідними параметрами):
При цьому коли ви в шаблонах генеруєте посилання, то можна робити зворотну операцію - відображати набір значень в готовий URI.
У інших фреймворків можуть бути інші схеми, наприклад CherryPy вміє, як схожий на Django спосіб завдання маппінга URI. так і автоматично, відповідно до структури програми знаходить якийсь метод якого об'єкта покликати з якими параметрами.
gro
Мабуть тому, що багато пайтоністи - це колишні php-програмісти, яким шкода стільки витраченого часу і сил на метушню з даними шаблонізатором.
Про туман - це ви даремно, як ви думаєте скільки nginx-конфігов в день я бачу? Зазирнувши до мене в профіль, можете здогадатися, що дуже багато. Як ви думаєте, якщо конфиг сповнений гівна, складається з купи рерайт, а також містить у собі такі речі, як location
\ .php. то якою мовою додаток, яке він обслуговує? Правильно здогадалися. І таких 95%, а якщо конфиг чистенький і простий, то це швидше за все Ruby / Python / erlang / node.js / Java.
сильно відрізняється від конфіга для пітона (взято з доки nginx)
Перечитав.
Не побачив нічого неправильного в своїх словах.
Хіба що можна було трохи простіше думку сформулювати бо це ж Хабр:
1 - саме поняття ЧПУ з'явилося після того як ці самі шляху зробили кривими. Спочатку коли була статика шляху були ЧПУ - папки, файліки ... але тоді не було такого поняття. Потім шляхи «поламали» бо працювати через гет-параметри було простіше, і передавати в параметрах цифрові індекси було простіше ... Десь це була інерція мислення, десь реальне спрощення. Потім раптом виявилося, що нормальні шляхи були краще, і їх різко стали реанімувати. Стали реанімувати на основі того що є - на основі кривих get-параметрів. Звідси і складнощі. Очевидне рішення це робити єдину точку входу, і далі вже працювати з нормальним запитом, з текстовими читабельними назвами «папок» і «файлів» і т.п. Але ось невдача - ми це все ліпимо знову таки на движок, в якому у нас все йде в цифровому вигляді ... Від них потрібно просто відмовитися і все.
2 - далі я говорив про те, що текстові імена не гірше цифрових, про те, що це ніяк не відіб'ється на продуктивності, і що один раз зробивши ти більше в це не лізеш ...
3 - ну і про пітон. Пітон так, гарна мова, має кілька помітних переваг над пхп, але у нього є «фатальний недолік» :))))) Пітон не варто на кожній машині, він трохи складніше в обслуговуванні, бо вимагає постійно живе демона з усіма наслідками, що випливають ... Попит на нього менше ... багатьох рішень у фронтендів може не бути - відразу переписуй ... шукай верстальника який знайомий з пітоном і пхп ... Пітон хороший як основа для команди вечножівущего і вічно доробляти проекту. А коли пишеш під все і вся, то у пхп альтернативи немає. І навіть якщо 80% твоїх проектів дозволятимуть використовувати пітон, то що робити з рештою 20%? Підтримувати свої навички, своє середовище розробки (включаючи бібліотеки, напрацювання, команду розробників і т.п.) на двох мовах? Відмовлятися від замовлень? Нав'язувати клієнту більш складне рішення бо тобі так простіше? І добре якщо 20%, тут дійсно простіше від них відмовитися ... Ну а якщо їх 50/50?
Головне писати добре, а на що вже не важливо ...