«Обычное PHP-приложение»

Читаю Django Book (книга о Python-фреймворке Django):

In contrast, other Web development platforms couple the URL to the program. In typical PHP (http://www.php.net/) applications, for example, the URL of your application is designated by where you place the code on your filesystem.

Может мне кто-то расскажет что такое «обычное PHP-приложение», в котором «URL вашего приложения определён местом,где размещён код в вашей файловой системы»? Даже веб-мастера блогами забытых сайтов знают о существовании mod_rewrite (если говорить про Apache), а интернет уже много лет содержит тысячи (если не сотни тысяч) рецептов по работе с ним, а так же альтернативные способы.

В итоге «обычные» (т. е. «встречающееся чаще других») «PHP-приложение» это, напротив, то, что отвечает принципам ЧПУ (это в России так REST называется, впрочем REST придуман по другому поводу).

P.S. ещё лингвисизм по отношению к PHP из той же книги:

If you’re experienced in another Web development platform, such as PHP or Java, you may be thinking, “Hey, let’s use a query string parameter!”, something like /time/plus?hours=3, in which the hours would be designated by the hours parameter in the URL’s query string (the part after the ?).

Поделиться
Отправить
14 комментариев
isagalaev (softwaremaniacs.org/about/) 2008

Кхм... :-)

Ругать людей за слабое знание предмета и при этом сравнивать REST и ЧПУ? :-)

REST никак не связан с ЧПУ. На самом деле, он даже рекомендует относиться к URL’ам, как к совершенно непрозрачным строкам, в которых никто не должен разбираться. Поэтому совершенно неважно, как они выглядят. Это важно с других точек зрения, но не с точки зрения REST’овости. ИМХО.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для softwaremaniacs.org/about/:

Я не говорил, что REST и ЧПУ связаны, я даже упомянул, что придуманы они по разным поводам. Лично мне показалось, что REST+его паттерны прямо указывают как формировать URL, причём, их организация напоминает ЧПУ 1 в 1. И, напротив, мне показалось, что REST строится таким образом, чтобы «самодокументироваться» именно для человека. Это ЧПУ.

Чем http://example.org/users/bolk не ЧПУ? Чем он не REST?

Евгений Степанищев (bolknote.ru) 2008

Комментарий для softwaremaniacs.org/about/:

В статье «REST Anti-Patterns» ( http://www.infoq.com/articles/rest-anti-patterns ) есть и такой: «Breaking self-descriptiveness». Значит, один из хороших паттернов REST делать самодокументированные строки URL.

crizis.livejournal.com 2008

ЧПУ (это в России так REST называется

это в России так SEF называется, и к REST никак не относится

Евгений Степанищев (bolknote.ru) 2008

Комментарий для crizis.livejournal.com:

Я объяснил свою позицию в двух коментариях. Если у вас есть аргументы — напишите.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для crizis.livejournal.com:

SEF — это Search Engines Friendly? Это не ЧПУ. ЧПУ — для человека, а не для поисковых машин.

Alisey (alisey.myopenid.com) 2008

Автор первой цитаты как бы говорит нам:
Когда пишешь программу на голом PHP, то самый простой способ сделать скрипт доступным извне — это положить его в htdocs. И чтобы не получилась каша приходится саму придумывать какие-то соглашения на размещение файлов и формат URL. А когда используешь фреймворк, например Jango, то проще всего размещать файлы так, как советует этот фреймворк, добрые люди уже подумали об оптимальной структуре.

Почему бы автору не привести сравнение с голым Пайтоном — не представляю. Наверное детская травма.

jahson.livejournal.com 2008

Комментарий для Евгения Степанищева:

Они больны, доктор.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для jahson.livejournal.com:

Шовинизм, ну :)

isysoev.livejournal.com 2008

Комментарий для Евгения Степанищева:

Как раз именно использование mod_rewrite подтверждает тезис автора книги о том, что в типичном PHP-приложении URL приложения определён местом, где размещён код в файловой системы. Без костыля в виде mod_rewrite ссылки, создаваемыми таким приложением, просто не будут работать. А насколько это типично, я вижу по регулярным вопросам в рассылке nginx о том, как переписать Апачевский RewriteRule’ы. Каким боком mod_rewrite относится к PHP-приложению ?

Евгений Степанищев (bolknote.ru) 2008

Комментарий для isysoev.livejournal.com:

Мы тут упираемся в связку Apache + mod_php — самое популярное решение, а mod_rewrite тут выглядит самым гибким способом роутинга.

Сам знаешь, что в связке nginx + FastCGI/PHP роутинг можно строить так, как это делают в Python — завернуть всё на один PHP-файл и обработать роутинг внутри него.

Да и на Apache + mod_php то же самое делается очень просто, есть масса способов, просто mod_rewrite людям нравится больше.

Даже если отбросить все эти рассуждения, то типичный сайт на PHP всё равно не выглядит как «куда положили файл, оттуда и вызвали», с mod_rewrite это сделано или ещё как, тут особо не важно, Python тоже ведь не сферический конь в вакууме, ему роутинг, бывает, тоже через mod_rewrite делают.

А сравнивать PHP с Django просто некорректно, первый — язык программирования (со всеми возможными методами роутинга), второй — framework (с одним, заданным методом).

Кстати, видел тебя на «РИТе», но не подошёл, ты был занят, встретились бы год назад — завалил бы вопросами по судьбе nginx.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для isysoev.livejournal.com:

Кстати, сделай себе OpenID delegation и сможешь подписываться своим сайтом здесь. Пропиши в <head> своего сайта:

<link rel=«openid.server» href=» http://www.livejournal.com/openid/server.bml%22 />

<link rel=«openid.delegate» href=» http://isysoev.livejournal.com%22 />

ещё лучше — сделать pavatar ( http://pavatar.com/ )

isysoev.livejournal.com 2008

Комментарий для Евгения Степанищева:

Я не сравниваю PHP и Django, так как не знаю ни первого, ни второго, я лишь констатирую факт, что типичный PHP-URL выглядит, как /page.php?и=куча&каких-то=параметров. Вот примеры, которые можно увидеть на достаточно известных сайтах:

http://www.facebook.com/apps/application.php?id=6333203805
http://vkontakte.ru/help.php?page=terms
http://img238.imageshack.us/my.php?image=5c08ee079470kw1.jpg

Для java, кстати, /page.jsp?параметры тоже не было редкостью. И такие URL’ы никого не беспокоили до тех пор, пока не оказалось, что они плохо индексируются тогдашними поисковиками

( http://www.sitepoint.com/article/search-engine-friendly-url ) или же поисковики понижают им ранг

( http://www.webconfs.com/dynamic-urls-vs-static-urls-article-3.php ) И народ, вместо того, чтобы переписывать приложения, решил проблему малой кровью — стал переписывать URL перед PHP. Но для PHP сам типичный PHP-URL от этого не изменился и программист продолжал мыслить именно в этом духе — «куда положили файл, оттуда и вызвали».

Что касается mod_rewrite, то, дело скорее не в том, нравится он больше или меньше, а в том, что зачастую люди просто не знают, как можно сделать по-другому или же не хотят: схема, когда веб-сервер с помощью простыни регулярных выражений переписывает для приложения URL, кажется им совершенно естественной. Я видел один проект на mod_perl, где URL переписывали с помощью нетривиальных RewriteRule’ов и разработчики не видели в этом ничего странного, хотя обработать всё это на mod_perl было бы куда проще.

Почему так произошло ? Потому что любые решения, и хорошие, и плохие, имеют свойство тиражироваться в блогах, в статьях на сайтах, а потом даже в книгах.

Что касается openid, то я так редко комментирую в форумах, что даже не охота парится на эту тему.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для isysoev.livejournal.com:

Типичный PHP URL выглядит не так, тем более сейчас, когда кучи сайтов делают на готовых CMS (например, Drupal, Joomla), которые поддерживают ЧПУ «из коробки». Нет никакого «типичного сайта на PHP», это такой же миф как «средний городской житель», так же как нет «типичного сайта на Python».

Просто «.php» в URL сразу заметно, остальные сайты, языковая принадлежность который неясна, в глаза не бросаются, вот и кажется, что большинство PHP URL сайтов сделаны кучей параметров. Вот по моему сайту заметно, что он на PHP сделан?

Кстати, есть масса сайтов, где основная масса URL сделана без GET-параметров, а 2-3 документа (вроде помощи, страницы «о нас» или чего-то такого) — с ними. На том же vkontakte большая часть урлов выглядит как http://vkontakte.ru/id3715294

Да, я в курсе почему стали избавляться от GET-параметров, сам принимал участие в этом процессе, всё-таки первый сайт я сделал в 1997 году.

Популярное