[php]человеко-понятный url

С этого и надо было начинать. То что веб-сервер реализован на том же языке - это не значит, что роутинг создаётся исключительно силами ЯП.

Покажи мне вариант, при котором он не будет работать :) (это и есть «из коробки»)

Семнадцать строчек вместо четырёх, всё скинуто в одну кучу, для валидации ещё 17 строчек надо будет, и всё равно требуется поддержка веб-сервера.

Я совсем запутался. Я говорю о реализации ЧПУ, исключительно средствами ЯП, без затрагивания конфигурации веб-сервера. Это возможно?

Тогда тебе вопрос на засыпку: WSGI - это веб-сервер или нет?

Тогда тебе вопрос на засыпку: WSGI - это веб-сервер или нет?

Не, это не веб-сервер.

Но это и не реализация исключительно средствами ЯП? Ведь, буду я использовать запускаемый сервер, синхронный или асинхронный, WSGI, или что угодно, у меня везде будет работать одинаково.

Семнадцать строчек вместо четырёх

Так внутри твоего bottle, думаешь, не 17 строчек?:) Посмотри на класс Router в исходниках.

всё скинуто в одну кучу

Потому что сделано для примера, на коленке. Немного усилий и прямых рук - и можно сделать мини-фреймвор, как твой bottle.

и всё равно требуется поддержка веб-сервера.

Одна строчка rewrite-а, для перекидывания всех запросов на index.php. Что-то аналогичное нужно и для python + fastCGI, кстати.

P.S. я сам сильно не люблю php, и люблю python, но тут в данном случае ваши аргументы, мягко говоря, неверны. На php вполне можно сделать нормальный роутинг без особых сложностей, хоть это и не исправит всех косяков языка.

Пример на Perl Dancer:

Если интересно, у меня оно будет так: MY_APP/url_map.php:

...
'/name=(\d+) => my_name_view(1)
...

MY_APP/classes/my/name.yaml

extends: my_object_db
table_name: people
table_fields:
    id
    name

MY_APP/classes/my/name/view.yaml

extends: my_view
title: Моё имя
...

MY_APP/classes/my/name/view.html

<div id="greeting"> Hello, {$name}!</div>

Кто о чём, а Балансер о своём монструозном борще:)

Что тебе в приведённом коде не нравится? :)

Что тебе в приведённом коде не нравится? :)

Да я не про код, я вообще про фреймворк. Какие-то yaml, автогенерации. Непрозрачно оно всё:)

Какие-то yaml, автогенерации.

Ну, цель у меня такая, минимизация писанины :) Ненавижу два раза писать одни и те же слова и считаю аморальной функцию копипаста :)

Непрозрачно оно всё:)

Дык, любая автоматизация скрывает часть процессов :) Контроллер в львиной долн проектов повторяется один и тот же из проекта в проект. Так что я давно и старательно делаю его автоматизированным, оставляя работу только над моделями и представлениями.

Но при желании можно почти всё вытаскивать наружу:

class my_name_view extends bors_page
{
    function content()
    {
        $renderer = new bors_renderer_smarty3;
        $object = bors_load('my_name', $this->id());
        $html = $renderer->render('name.html', $object->data());
        return $html;
    }
}

Ну, или даже дальше по цепочке :)

Только очень редко когда нужно.

Так внутри твоего bottle, думаешь, не 17 строчек?:) Посмотри на класс Router в исходниках.

А внутри php вообще C. Какая разница?

Потому что сделано для примера, на коленке. Немного усилий и прямых рук - и можно сделать мини-фреймвор, как твой bottle.

А потом ещё подключить шаблоны. А потом ещё то и сё. И получится вместо элегантного решения, которое вложено в один стокилобайтовый файл на python, не требующий ничего, кроме python2.5, получим сложное решение, которое всё равно для роутов будет использовать настройки веб-сервера.

Что-то аналогичное нужно и для python + fastCGI, кстати.

Превратить python в php можно, не спорю. Но кто в здравом уме (php-шников в расчёт не берём) будет использовать подобную схему, когда кладутся файлы .py, и сервер уже ищет их по каталогу и исполняет написанное в них. Это же возврат в каменный век.

P.S. я сам сильно не люблю php, и люблю python, но тут в данном случае ваши аргументы, мягко говоря, неверны. На php вполне можно сделать нормальный роутинг без особых сложностей, хоть это и не исправит всех косяков языка.

Тему и задачу посмотрите. PHP это как винда, на ней можно сделать много чего, но большинство из этого «много чего» будет неэффективно, громоздко, усложнено и неэлегантно. Это тот случай, когда вместо того, чтобы сделать один раз и хорошо, делают «лишь бы работало», а потом снабжают набором костылей и подпорок. Эффективность и надёжность такой схемы - под большим вопросом.

А внутри php вообще C. Какая разница?

Такая.

А потом ещё подключить шаблоны. А потом ещё то и сё. И получится вместо элегантного решения, которое вложено в один стокилобайтовый файл на python, не требующий ничего, кроме python2.5, получим сложное решение, которое всё равно для роутов будет использовать настройки веб-сервера.

PHP, а точнее mod_php - базовая вещь, на уровне чистого WSGI по концепции. Т.е. работать с ним можно, но не интересно, так как надо возиться на низком уровне. Всё, что поверх него накручивается - уже фреймворк.

Вы сравниваете чистый php и питон с уже написанным фреймворком. Это неправильно, надо сравнивать bottle.py с его аналогом на php.

Берём, пишем на php стокилобайтный файл с роутингом, шаблонами и прочим счастьем, и получаем аналог. Тогда и сравниваем. Вряд ли оно будет элегантнее питоновского варианта, так как язык не тот, но в общем смысл будет одинаков.

Превратить python в php можно, не спорю. Но кто в здравом уме (php-шников в расчёт не берём) будет использовать подобную схему, когда кладутся файлы .py, и сервер уже ищет их по каталогу и исполняет написанное в них.

Так никто и не собирается так делать. На php можно сделать всё в виде одного index.php, который будет точкой входа, и на подключаемых к нему файлах, а-ля питоновские модули. То, что многие делают не так - их проблема, на самом деле.

И минимальная настройка вебсервера нужна и для питона, и для пхп. Без этого никак.

PHP это как винда, на ней можно сделать много чего, но большинство из этого «много чего» будет неэффективно, громоздко, усложнено и неэлегантно.

Да, есть такое. Однако не настолько оно будет громоздко и неэффективно, если сделать это грамотно.

Вы сравниваете чистый php и питон с уже написанным фреймворком. Это неправильно, надо сравнивать bottle.py с его аналогом на php.

Я сравниваю средства для построения веб-приложений для новичка.

Человеку то, что bottle.py написан на python - неинтересно, по большому счёту. Ему хочется создавать какие-то веб-приложения, хотя бы научиться этому. В bottle.py он берёт bottle.py (из репозитория своего дистрибутива или из питоновского), берёт в руки туториал, и видит

- шаблоны (которые он сам будет рисовать, и не перемешивать их вагонами логики, как обычно идёт в php, где всё начинается с обычных вставок, а заканчивается развратом)

- и sql-запросы (которых ему уже хватит для хранения данных)

- попутно он разбирается с python.

В php же, чтобы ему делать так же, ему нужно сначала найти фреймворк (какой, как узнать? те пацаны, которые сказали, что php это модно, про фреймворк и не говорили, а инструкции на php.net учат именно делать вставки, затем изучить php на базовом уровне (при этом уже привыкая делать неправильно), настроить веб-сервер под запросы и редиректы, и только уже потом начать разрабатывать правильно, попутно переучиваясь.

... почувствуйте разницу...

То, что многие делают не так - их проблема, на самом деле.

Это культура языка. Их учат именно этому. На bottle.py никто не учит перемешивать логику с шаблонами, деплоить через ftp-сервер и писать в кодировке cp1251. Можно и в подвале выучиться и стать великим учёным, но лучше всё-таки начать с азбуки.

И минимальная настройка вебсервера нужна и для питона, и для пхп. Без этого никак.

run(port=80) :)

Да, есть такое. Однако не настолько оно будет громоздко и неэффективно, если сделать это грамотно.

drupal и wordpress до сих пор тормозят на более чем среднем железе. Я просто взял drupal7 и кинул его на сервер с двумя ядрами и ведром ОЗУ, выполнил типовую инсталляцию. После этого ЛЮБАЯ страница из тех, что создал установщик, открывалась секунд 10. Я посмотрел в интернете - такое у многих. И им в ответ одни некомпетентные сообщения, что опять же показывет культуру php-шников.

Если можно сделать грамотно - чегож не делают?

Я сравниваю средства для построения веб-приложений для новичка.

В общем да, в этом случае вы правы.

run(port=80) :)

Ага, однопоточно и медленно :)

drupal и wordpress до сих пор тормозят на более чем среднем железе.

Если можно сделать грамотно - чегож не делают?

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

Как только начинаешь отходить от заранее забитого роутинга и текстовых конфигов, начинаются проблемы. Начиная с медленного EAV (свойство - тип - значение и куча промежуточных моделей, JOIN-ы и так далее), заканчивая какими-то извращениями для расстановки универсальных блоков в шаблоне.

Чем более универсальным становится проект, тем больше сложного кода для всех случаев приходится прикручивать. И другого пути в данном случае нет, т.к. пользователю таких продуктов нужно именно «поставить в инсталлере и ткнуть мышкой в админке». А вот на тех же джангообразных фреймворках тормозов заметно меньше, просто by-design.

Для примера - есть django-cms, который, если натыкать на него мышкой модулей, как на друпал, вполне себе рождает сотню запросов к БД на пустом месте. И язык тут уже не виноват.

Ага, однопоточно и медленно :)

А хотя приношу свои извинения, это не всегда так, не о том подумал.

И минимальная настройка вебсервера нужна и для питона, и для пхп. Без этого никак.

Он вообще-то подразумевал другое: python: mod_wsgi php: mod_php + mod_rewrite + AllowOverride если на .htaccess

Вот тут вся разница. В том, что подчеркнуто. При этом весьма нескучные и прохладные баллады о том, как умеет тормозить mod_rewrite и парсер AccessFile не помещаются на мой винт даже.

Ага, однопоточно и медленно :)

Concurrency Level: 5
Time taken for tests: 4.213 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0

AMD e350

Что же там у новичка за нагрузки такие? Кроме того, при увеличении нагрузок не нужно будет ничего переписывать, есть и run(server=), и при настройке сервера не нужно переписывать с .htaccess на правила nginx.

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

У php принцип такой - «что ты пишешь, то ты и получишь». А bottle.py изначально учит не писать неправильно. Юзер при возникновении проблемы лучше потратит 5 минут, чтобы посмотреть в справочник, чем воткнёт непонятно как работающую строку, но «зато работает».

для сравнения, там же - hello, world.php

Server Software: Apache/2.2.22
Server Hostname: 127.0.0.1
Server Port: 80

Document Path: /test.php
Document Length: 61 bytes

Concurrency Level: 5
Time taken for tests: 1.206 seconds
Complete requests: 1000

Да, промышленный сервер обогнал встроенный тестовый сервачок аж в 4 раза. Но новичку-то с этого что?

drupal и wordpress до сих пор тормозят на более чем среднем железе

дык опенсорс
фамильная черта

Да, довольно интересно, спасибо.

Действительно, не очень прозрачно, в частности я вообще ни хрена не понял по взаимодействию с БД, да и ООП мне пока не очень-то даётся, так что мой пример (и Dancer) мне в целом понятнее.

Достал из базы - сунул в хэш - шаблонизатором достал из хэша, что следует и показал.

в частности я вообще ни хрена не понял по взаимодействию с БД

А там ORM. Класс my_name содержит имя базы данных (может вычисляться по дефолту), таблицы (может вычисляться по дефолту), описание полей и их мапинг на свойства объекта, если он не один-к-одному. В принципе, тоже может генерироваться автоматически, но пока такая фишка не востребовалась.

Функция bors_load($class_name, $id) (наследие тяжёлого детства отсутствия статического позднего связывания) загружает (в частности) из БД указанный объект с указанным ID. После загрузки методы ->id() и ->name() класса будут возвращать значения соответствующих полей записи в БД.

так что мой пример (и Dancer) мне в целом понятнее.

Понятно, что если всё расписать, то всегда понятнее. Только и писанины сразу больше. Для большого проекта — критично :)

Достал из базы

А если завтра нужно поменять бэкенд? У меня это может быть заменой одной строчки. Вся остальная работа останется как есть.

шаблонизатором достал из хэша

Опять же, а если шаблонизатор поменять на другой? У меня это может вообще без кодирования решаться, заведением другого файла шаблона :)

Метод, выводящий контент, в непереопределённом виде, находит одноимённый с отображаемым файлом шаблон (с соответствующим расширением), вызывает соответствующий шаблонизатор, скармливает ему данные объекта и применяет шаблон. В 99.9% случаев это однотипное действие для нескольких базовых принципов, так зачем его копировать из класса в класс, из проекта в проект? :)

Машина должна работать. Человек — думать. © IBM :)

А там ORM...

Будучи ламером, всё же не стал бы рекомендовать ORM для обучения. SQL таки надо хотя бы немножко знать, и потом будет понятнее, для чего ORM тебе нужен. %)

Понятно, что если всё расписать, то всегда понятнее. Только и писанины сразу больше.

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

А если завтра нужно поменять бэкенд? У меня это может быть заменой одной строчки. Вся остальная работа останется как есть.

Меняем в config.yml (или в самом тексте модуля, то, что пишет разработчик в Dancer - по сути, модуль) буквально пару строк, при этом кейворд database работает всё таким же образом, если в запросы не понапихано специфических для DBMS вещей и продолжаем веселиться.

Опять же, а если шаблонизатор поменять на другой? У меня это может вообще без кодирования решаться, заведением другого файла шаблона :)

Пожалуйста. Таким же образом в config.yml меняем Template::Toolkit на что-нибудь другое, опять же, если шаблоны не очень сложные, можно ограничиться даже просто указанием шаблоновских «скобок», я не знаю, как они по науке называются.

Аналогично меняются механизмы управления сессиями, разграничения прав доступа, авторизации и т.п. Я думал, это все фреймворки умеют.

Инновационно и нанотехнологично тут, на мой непросвещённый взгляд, разве что автоматическое определение имени и расширения шаблона, у меня в моём единственном проекте есть нечто подобное, выглядит так:

get '/post/*/*' => sub {
		
	my ($post_lang, $post_name) = splat; # << post_name - это url поста и 
	                                          одновременно имя поста, а $post_lang
	                                          уточняет, доставать ли из базы какой-то
	                                          один вариант или все
    ...
    # тут разный быдлокод, но буквально пара строчек 
 	...
 	my $templ = ($post_lang eq "bl") ? "show_one_bilingual.tt" : "show_one.tt";
 	# ^ выбираем швблон в зависимости от 
 	 
 	template "$templ" , { # << вот такая автоматика
		'post' => $post, # << волшебный hashref, из которого шаблонизатор достаёт
		                 #    заголовок, текст, категории, чёрта в ступе
		                 
                ... # немного лишних параметров, в частности, "словари" в виде 
                    # хэшей, в которых написано, как по-русски будет permalink
	};
};

Всё это к тому, что

а) всякие ништяки есть во всех фреймворках, они на то и фреймворки

б) учиться лучше на маленьких и скромных фреймворках, потом с большими и жырными будет проще разобраться, поэтому я за микрофреймворки для самоделкиных на каком угодно языке, но для этих целей против рельсов, борщей, каталистов и прочей тяхёлой артиллерии.

Будучи ламером, всё же не стал бы рекомендовать ORM для обучения

Ну, это само собой. Я свой фреймворк никогда и не позиционировал с такой целью :D Только для работы…

Меняем в config.yml (или в самом тексте модуля, то, что пишет разработчик в Dancer - по сути, модуль) буквально пару строк

Я вот про такое: «SELECT name FROM people WHERE name = ?»

Когда мне (очень-очень редко) приходится писать SQL-запрос (и то не в таком виде, а что-то типа "->select('people', 'name', array('name' => $name)))"), я считаю, что у меня где-то ошибка в концепции :)

а) всякие ништяки есть во всех фреймворках, они на то и фреймворки
б) учиться лучше на маленьких и скромных фреймворках

Не спорю, так и есть :)

Не, если вопросы возникают как в исходном посте, то нужно побольше делать руками, и запросы к базе в том числе. И то любой фреймворк очень много абстрагирует, например я ничего так и не выучил про http-запросы и cookies, а должен был.

у меня простенький сайт-визитка, и чпу я там сделал так, - в nginx.conf дописал:

try_files $uri $uri/ /index.php?path=$uri&$args;

if (isset($_GET['path'])) {
  foreach (explode('/', $_GET['path']) as $null) {
    if (strlen($null) > 0) {
      $path[] = $null;
    }
  }
  if (in_array($path[0], array('Main_Page', 'About'))) {
    include('modules/'.$path[0].'.php');
  }
  else {
    include('modules/error.php');
  }
}
else {
  include('modules/default.php');
}

Если в аргументах будет path, то все летит, надо местами поменять.