Загрузку библиотек надо делать с умом — и все будут довольны.
Естественно PHP не настолько быстр как mod_rewrite. Но знаете что? Под нагрузкой и апач весьма убойная штука. Потому оно у меня бегало бы на nginx/lighttpd + fastcgi. А в таком случае я бы долго проклинал того разработчика, благодаря которому я бы сидел и давился над регекспами при переводе их для nginx/lighttpd.
Угу, есть, конечно. Только вот задолбаетесь переделывать пачку реврайтов в его формат. А потом захотели попробовать lighttpd — а у него описание правил опять отличается…
Поверьте, опыт большой — не зря советую. И себе и другим единая точка входа облегчает жизнь. И сильно.
Хотите скажу почему куча правил для mod_rewrite зло для такой задачи? А перенесите все это добро под lighttpd / nginx + php-cgi.
И я очень радуюсь когда приложения написаны действительно грамотно — их при этом не приходится пилить напильником.
Насчет единой точки входа — так и у больших фреймворков на php, так и у django/rails/merb.
Вы домой тоже ведь не только через парадное, но и через балкон и форточки заходите?
Такая архитектура позволяет в одном месте приложения обрабатывать все входящие данные и доставлять их в нужные контроллеры/действия. И так у всех нормальных фреймворков сделано.
У правильного приложения одна точка входа — index.php в корне. И соответственно все относительные пути строить не вызывает проблем.
Лучше устанавливать все пути в конфигурационном файле, в котором использовать __FILE__ — и никаких проблем не будет.
Использую вот уже два года — проблем даже при обновлении не возникает. Хотя было два косяка — в Postfix отказался работать TLSv3, оставил v2 и все продолжило работать чудесно. Второй косяк — смена конфигов апача и тормоза из-за небольших косяков в полученом сборнике. Полечилось вдумчивым чтением конфигов и выкашиванием лишнего/повторяющегося/устаревшего.
Метод защиты не то чтоб от дурака, а от кого потупее.
Неужели так тяжело проверить правильность параметров команды перед ее запуском хотя бы тем же find?
Естественно PHP не настолько быстр как mod_rewrite. Но знаете что? Под нагрузкой и апач весьма убойная штука. Потому оно у меня бегало бы на nginx/lighttpd + fastcgi. А в таком случае я бы долго проклинал того разработчика, благодаря которому я бы сидел и давился над регекспами при переводе их для nginx/lighttpd.
Поверьте, опыт большой — не зря советую. И себе и другим единая точка входа облегчает жизнь. И сильно.
Скорее как одтельный вход возле для каждого стеллажа. Что не так уж удобно.
И я очень радуюсь когда приложения написаны действительно грамотно — их при этом не приходится пилить напильником.
Насчет единой точки входа — так и у больших фреймворков на php, так и у django/rails/merb.
Такая архитектура позволяет в одном месте приложения обрабатывать все входящие данные и доставлять их в нужные контроллеры/действия. И так у всех нормальных фреймворков сделано.
Лучше устанавливать все пути в конфигурационном файле, в котором использовать __FILE__ — и никаких проблем не будет.
Дэбиан хорош, но уж чересчур консервативен.
Неужели так тяжело проверить правильность параметров команды перед ее запуском хотя бы тем же find?