«Обычное 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 ?).
Кхм... :-)
Ругать людей за слабое знание предмета и при этом сравнивать REST и ЧПУ? :-)
REST никак не связан с ЧПУ. На самом деле, он даже рекомендует относиться к URL’ам, как к совершенно непрозрачным строкам, в которых никто не должен разбираться. Поэтому совершенно неважно, как они выглядят. Это важно с других точек зрения, но не с точки зрения REST’овости. ИМХО.
Комментарий для softwaremaniacs.org/about/:
Я не говорил, что REST и ЧПУ связаны, я даже упомянул, что придуманы они по разным поводам. Лично мне показалось, что REST+его паттерны прямо указывают как формировать URL, причём, их организация напоминает ЧПУ 1 в 1. И, напротив, мне показалось, что REST строится таким образом, чтобы «самодокументироваться» именно для человека. Это ЧПУ.
Чем http://example.org/users/bolk не ЧПУ? Чем он не REST?
Комментарий для softwaremaniacs.org/about/:
В статье «REST Anti-Patterns» ( http://www.infoq.com/articles/rest-anti-patterns ) есть и такой: «Breaking self-descriptiveness». Значит, один из хороших паттернов REST делать самодокументированные строки URL.
это в России так SEF называется, и к REST никак не относится
Комментарий для crizis.livejournal.com:
Я объяснил свою позицию в двух коментариях. Если у вас есть аргументы — напишите.
Комментарий для crizis.livejournal.com:
SEF — это Search Engines Friendly? Это не ЧПУ. ЧПУ — для человека, а не для поисковых машин.
Автор первой цитаты как бы говорит нам:
Когда пишешь программу на голом PHP, то самый простой способ сделать скрипт доступным извне — это положить его в htdocs. И чтобы не получилась каша приходится саму придумывать какие-то соглашения на размещение файлов и формат URL. А когда используешь фреймворк, например Jango, то проще всего размещать файлы так, как советует этот фреймворк, добрые люди уже подумали об оптимальной структуре.
Почему бы автору не привести сравнение с голым Пайтоном — не представляю. Наверное детская травма.
Комментарий для Евгения Степанищева:
Они больны, доктор.
Комментарий для jahson.livejournal.com:
Шовинизм, ну :)
Комментарий для Евгения Степанищева:
Как раз именно использование mod_rewrite подтверждает тезис автора книги о том, что в типичном PHP-приложении URL приложения определён местом, где размещён код в файловой системы. Без костыля в виде mod_rewrite ссылки, создаваемыми таким приложением, просто не будут работать. А насколько это типично, я вижу по регулярным вопросам в рассылке nginx о том, как переписать Апачевский RewriteRule’ы. Каким боком mod_rewrite относится к PHP-приложению ?
Комментарий для 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.
Комментарий для 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/ )
Комментарий для Евгения Степанищева:
Я не сравниваю 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, то я так редко комментирую в форумах, что даже не охота парится на эту тему.
Комментарий для 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 году.