вот именно.
Реврайт заточен для Урл преобразований, а вы мне доказываете что в этом деле — ваш доморощенный скрипт будет быстрее и эффективнее ))
я тоже делал сайты и скриптовым фронт-контроллером и на реврайте и без… и у меня сформировалось свое мнение ))
которое без весомых аргументов вы не измените…
Я ждал этой строчки ))))
Она еще раз жирно доказывает — что чтобы ваш вариант с Единым скриптом фронт-контроллером, для нормальной работы требует Кучи Костылей, причем опятьже на Реврайте ))
и поверьте, это самый простой и далеко не последний костыль который придется вам прописать…
а кто сказал что что не будет? ))))
ведь мы щас говорим о конкретных случаях, когда есть только Апач и Пхп и Реврайт…
1) если говорить балансировке нагрузки, о nginx или lighthttpd… то это уже выходит за рамки данного обсуждения. и Опятьже не отменяет преимуществ использования реврайта.
Использование одного скрипта как Фронт-контроллера удобно когда пишется универсальный сайт. чтоб он заработал на большинстве хостингов…
но всем известно что, Универсальное != Оптимальное.
в данном случае более оптимальным и производительным вариантом является использование Реврайта… странно что вы с этим спорите
зря!
когда все запросы обрабатывает Один скрипт — то даже ошибка в пути до картинки в CSS-файле, будет каждый раз заставлять Апач запускать ПХП ) чтоб показать страницу 404 )
а если разрулить это через Реврвйт то апач сразу скажет что нет такого файла )
2) Нет. мощь реврайта как раз в том, что вы ОДИН раз напишите ОБЩИЕ правила для вашего раздела, и все!
Если предполагается что часть Урла будет динамической, то выделите их в regex-группу и передавайте в скрипт…
а если ОЧЕНЬ СИЛЬНО надо поменять адресацию на сайте, то придется менять Любую карту Урлов хоть на Реврайте хоть в Скрипте )
mod_rewrite занимается разбором Урлов )))
и НИКАК не мешает нам отображать красивые и информативные страницы Ошибок…
с ним все получается очень быстро и гибко)
1) отсекать Апачем? тоесть возвращаемся к необходимости mod_rewrite )))
2) очень просто. Несуществующие УРЛы это те которые не описаны как Валидные среди моих правил! и для которых нет необходимости запускать ПХП и его обработчики вообще…
3) очень просто. вызывайте из Реврайта не статичную 404 страницу, а конкретный модуль обработки ошибок на PHP, ведь это вам никто не запрещает делать.
Если заказчик хочет чтото Неправильное — надо объяснить ему, что он неправ и почему…
в вашем случае, например, Странная «Хотелка» заказчика полностью базовый принцип функционирования Веба, что Урл это идентификатор страницы в сети Интернет, и если он будет всегда меняться то клиент не сможет вернуться к понравившемуся товару, следовательно разочаруется и купит его у ваших конкурентов…
а в итоге Заказчик свалит все на вас и заявит что Вы плохо работаете, так как сайт неэффективен и не приносит прибыли…
сами себе яму роете…
не совсем так.
сначала выделяется логика адресации в каждом Разделе, а потом для каждого раздела пишется несколько регулярок, описывающих в Общем виде — его возможные подстраницы…
mod_rewrite это мощный инструмент для обработки урлов. специально созданный и оптимизированный для этого…
когда вы в скрипте делаете свой обработчик Урлов, вы тратите время на изобретение велосипеда, это факт!
к томуже вы заставляете апач запускать обработчик ПХП при КАЖДОМ запросе, даже когда посетитель пытается запросить ошибочный урл, или даже несуществующий файл…
Ваш инет магазин работает по принципу?:
1) седня товар доступен по адресу: site.ru/catalog/goods-9786.html
2) на сайт пришли Поисковики и проиндексировали его…
3) завтра вы в админке прописали другое правило… и урлы товаров доступны по адресам типа site.ru/catalog/super_goods-sony_987987.html
4) все посетители пришедшие с поисковиков попадают на страницу 404?
и без тестов ясно что с mod_rewrite диспетчеризация запросов будет работать быстрее.
подумайте сами:
— правила mod_rewrite начинают работать еще ДО того как апач передал управление Php скрипту. и далее при совпадении одного из правил — апач вызовет php скрипт с конкретными входными параметрами. ив самом скрипте НЕТ необходимости вычислять что запросил пользователь! Можно просто запустить соответствующий контроллер или функцию…
— не секрет что публичному серверу приходится обрабатывать Кучу невалидных запросов (ошибочные перенаправления с других серверов, сканирование сервера различными червями, устаревшие ссылки и т.д.). mod_rewrite поможет все эти запросы сразу отдавать статической странице ошибок, НЕ ЗАПУСКАЯ PHP вообще…
— кстати, хостинга где нет mod_rewrite ) я давно уже не встречал )
поправка.
MVC это все таки паттерн ) а не вид Движков.
Движок простой но УЖЕ есть серьезные ошибки в архитектуре.
1) инклюдите непроверенные переменные, угадайте во что это может обернуться? ))
2 class Controller extends ASfMVC_Controller { } зачем этот пустой промежуточный контроллер?
3) непонятно почему базовые сущности Контроллеров и моделей у вас реализованы через плагины…
4) если покопаться то еще много можно найти…
нужно? только Пхп?
Хотите сказать, у всех соседних языков множество ...DSL уже прекрасно реализовано?
насчет смутности местами — согласен. но подобные проблемы есть и у других языков. Та же Java, python, perl… мажорные версии теряют совместимость с предыдущими как раз потому что исправляются проблемы в архитектуре.
>А почему при таком «высоком уровне абстракции» программисты все еще пишут SQL-запросы в стиле «а я знаю, чо такое 'конкатенацыя строк!!!1'»?
это проблемы тех программистов ) но не языка
>В PHP надо было бы встроить возможность писать SQL-запросы прямо в язык (да-да, взял, и написал $rows = SELECT * FROM mytab WHERE myfield = 256). Где это?
Одному захочется встроить в Пхп нативную работу с SQL, второй скажет Встройте туда еще работу со всем подмножеством SGML и т.д… Что это за монстр получится? и кому он будет нужен после этого… такой язык изначально выроет себе могилу.
Все нужно в меру. и модули в Пхп(да и в других языках) вполне нормальное решение.
я просто о том, что по возможности, если мы пишем код на языке А, то и оперировать мы должны сущностями и возможностями языка А.
тогда у нас будет совместимость и работоспособность кода на всех поддерживаемых им платформах.
> if (PHP_OS=='WINNT') throw new mustDieException();
Если заказчик хочет, то его проект будет крутится и на винде и на любой платформе которую он только придумает. Он платит деньги и «Хочет» — а разработчик должен сделать чтобы код работал )
Реврайт заточен для Урл преобразований, а вы мне доказываете что в этом деле — ваш доморощенный скрипт будет быстрее и эффективнее ))
я тоже делал сайты и скриптовым фронт-контроллером и на реврайте и без… и у меня сформировалось свое мнение ))
которое без весомых аргументов вы не измените…
Она еще раз жирно доказывает — что чтобы ваш вариант с Единым скриптом фронт-контроллером, для нормальной работы требует Кучи Костылей, причем опятьже на Реврайте ))
и поверьте, это самый простой и далеко не последний костыль который придется вам прописать…
ведь мы щас говорим о конкретных случаях, когда есть только Апач и Пхп и Реврайт…
1) если говорить балансировке нагрузки, о nginx или lighthttpd… то это уже выходит за рамки данного обсуждения. и Опятьже не отменяет преимуществ использования реврайта.
Использование одного скрипта как Фронт-контроллера удобно когда пишется универсальный сайт. чтоб он заработал на большинстве хостингов…
но всем известно что, Универсальное != Оптимальное.
в данном случае более оптимальным и производительным вариантом является использование Реврайта… странно что вы с этим спорите
когда все запросы обрабатывает Один скрипт — то даже ошибка в пути до картинки в CSS-файле, будет каждый раз заставлять Апач запускать ПХП ) чтоб показать страницу 404 )
а если разрулить это через Реврвйт то апач сразу скажет что нет такого файла )
но ВЫ же сами этого захотели. чтоб Урл был красивый и умный )))
Если предполагается что часть Урла будет динамической, то выделите их в regex-группу и передавайте в скрипт…
а если ОЧЕНЬ СИЛЬНО надо поменять адресацию на сайте, то придется менять Любую карту Урлов хоть на Реврайте хоть в Скрипте )
и НИКАК не мешает нам отображать красивые и информативные страницы Ошибок…
с ним все получается очень быстро и гибко)
2) очень просто. Несуществующие УРЛы это те которые не описаны как Валидные среди моих правил! и для которых нет необходимости запускать ПХП и его обработчики вообще…
3) очень просто. вызывайте из Реврайта не статичную 404 страницу, а конкретный модуль обработки ошибок на PHP, ведь это вам никто не запрещает делать.
в вашем случае, например, Странная «Хотелка» заказчика полностью базовый принцип функционирования Веба, что Урл это идентификатор страницы в сети Интернет, и если он будет всегда меняться то клиент не сможет вернуться к понравившемуся товару, следовательно разочаруется и купит его у ваших конкурентов…
а в итоге Заказчик свалит все на вас и заявит что Вы плохо работаете, так как сайт неэффективен и не приносит прибыли…
сами себе яму роете…
сначала выделяется логика адресации в каждом Разделе, а потом для каждого раздела пишется несколько регулярок, описывающих в Общем виде — его возможные подстраницы…
когда вы в скрипте делаете свой обработчик Урлов, вы тратите время на изобретение велосипеда, это факт!
к томуже вы заставляете апач запускать обработчик ПХП при КАЖДОМ запросе, даже когда посетитель пытается запросить ошибочный урл, или даже несуществующий файл…
1) седня товар доступен по адресу: site.ru/catalog/goods-9786.html
2) на сайт пришли Поисковики и проиндексировали его…
3) завтра вы в админке прописали другое правило… и урлы товаров доступны по адресам типа site.ru/catalog/super_goods-sony_987987.html
4) все посетители пришедшие с поисковиков попадают на страницу 404?
действительно… СЕО-шники пищат )))
подумайте сами:
— правила mod_rewrite начинают работать еще ДО того как апач передал управление Php скрипту. и далее при совпадении одного из правил — апач вызовет php скрипт с конкретными входными параметрами. ив самом скрипте НЕТ необходимости вычислять что запросил пользователь! Можно просто запустить соответствующий контроллер или функцию…
— не секрет что публичному серверу приходится обрабатывать Кучу невалидных запросов (ошибочные перенаправления с других серверов, сканирование сервера различными червями, устаревшие ссылки и т.д.). mod_rewrite поможет все эти запросы сразу отдавать статической странице ошибок, НЕ ЗАПУСКАЯ PHP вообще…
— кстати, хостинга где нет mod_rewrite ) я давно уже не встречал )
MVC это все таки паттерн ) а не вид Движков.
Движок простой но УЖЕ есть серьезные ошибки в архитектуре.
1) инклюдите непроверенные переменные, угадайте во что это может обернуться? ))
2 class Controller extends ASfMVC_Controller { } зачем этот пустой промежуточный контроллер?
3) непонятно почему базовые сущности Контроллеров и моделей у вас реализованы через плагины…
4) если покопаться то еще много можно найти…
Хотите сказать, у всех соседних языков множество ...DSL уже прекрасно реализовано?
насчет смутности местами — согласен. но подобные проблемы есть и у других языков. Та же Java, python, perl… мажорные версии теряют совместимость с предыдущими как раз потому что исправляются проблемы в архитектуре.
это проблемы тех программистов ) но не языка
>В PHP надо было бы встроить возможность писать SQL-запросы прямо в язык (да-да, взял, и написал $rows = SELECT * FROM mytab WHERE myfield = 256). Где это?
Одному захочется встроить в Пхп нативную работу с SQL, второй скажет Встройте туда еще работу со всем подмножеством SGML и т.д… Что это за монстр получится? и кому он будет нужен после этого… такой язык изначально выроет себе могилу.
Все нужно в меру. и модули в Пхп(да и в других языках) вполне нормальное решение.
тогда у нас будет совместимость и работоспособность кода на всех поддерживаемых им платформах.
> if (PHP_OS=='WINNT') throw new mustDieException();
Если заказчик хочет, то его проект будет крутится и на винде и на любой платформе которую он только придумает. Он платит деньги и «Хочет» — а разработчик должен сделать чтобы код работал )