то есть, по сути, используя ErrorDocument в противовес mod_rewrite, мы сужаем список техтребований для хостинга (крайне незначительно, я прекрасно понимаю, но «бесплатно» — почему бы и нет), и резко снижаем трудозатраты первой линии саппорта на техподдержку связанную с механизмом роутинга.
сразу оговорим, что плюсы эти не вселенского масштаба, а мелкие, иначе все уже давно сидели бы на ErrorDocument =)
1. mod_rewrite есть не везде
2. где он есть — очень часто бывает отключен. включить его, даже из панели управления хостингом, среднестатистическому пользователю CMS — маленький подвиг.
3. для пользователя интструкция «добавить вот эту простую строку в любое место файла» гораздо понятнее аналога для mod_rewrite
4. mod_rewrite может активно использоваться на сайте для SEO, например, при этом придётся внедрять обработку 404 в существующие правила. либо наоборот, настроена обработка 404 через mod_rewrite, и нужно внести несколько правил для SEO — просто скопировав правила из инстуркций в интернете (а так все и делают, поверьте) юзер всё разломает.
сразу скажу единственный известный мне минус: апач не умеет отключать нотификацию в error_log о том, что файл не найден, при срабатывании ErrorDocument 404. получаем по одной записи в error_log для каждого срабатывания. есть патчи, отключающие это, но на shared их естественно вам никто не поставит.
Если говорить о статичных малостраничниках, то подход имеет право на жизнь, я ж разве спорю…
Но как только речь зайдёт о расширении, вы сядете в лужу. Другой движок в другом каталоге? Не смешно. В усложнённом проекте нужна унификация, нужен полный контроль за роутингом, итп. Возможно, это будет сюрпризом, но как раз здесь и реализован KISS ;)
принцип плох тем, что как только вы придёте к необходимости создать нечто большее, чем набор из десяти статичных страниц (каталог товаров, например, себе представляете?), весь ваш принцип придётся срочно перетачивать на роутинг изнутри cms без вмешательства вебсервера.
надеюсь, что к тому времени вы ещё не успеете написать много кода =))
в том виде, как предлагает автор статьи, механизм роутинга годится только для говносайтов на 10-15 страниц. впрочем, справедливости ради стоит отметить, что автор ни на что большее не претендует и явно указывает это в статье.
ошибка автора в том, что он сравнивает свой наколенный подход с крупными коробочными CMS, применительно к которым роутинг через файловую систему слегка отдаёт сумасшедшинкой.
просто тот ад с использованием FS, который вы предложили, создаёт у меня впечатление, что вы несколько некомпетентны в рассматриваемой теме, и только-только начали изобретать свой велосипед. в то время как разработчики всех перечисленных вами CMS прошли эту стадию много лет назад =)
Нет уж, позвольте. Вы противопоставляете mod_rewrite и ErrorDocument, утверждая, что последний хуже в рамках рассматриваемой задачи. Я задаю конкретный вопрос: чем он хуже?
Это Intel Wireless Display, на нём в игры не поиграешь, плюс артефакты сжатия.
Есть технология, которая действительно называется WiDi (она же Wireless HD). Там идет реалтайм поток без сжатия, можно в игры играть.
Брр, вник в тему. Совершенно некорректно называют это безобразие с перекодированием как WiDi. У Intel есть технология Intel Wireless Display, которая представлена в статье на thg и в этой статье на хабре. Но с реальной технологией WiDi это не имеет ничего общего.
Вот, например, телевизор, который умеет нормальный WiDi: www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?partNumber=KDL52XBR10&catalogId=10551&storeId=10151&langId=-1#overview
Там никакого сжатия, передача fullhd без потерь, и естественно не используется WiFi, пропускная, как я уже говорил, 4Gbps.
«вот тут» пишут совсем о другом, вы прочитайте внимательно. там сжатие потока на лету, передача по WiFi в коробку, которая раскодирует и показывает. статье как бы год уже.
не сравнивайте тёплое с мягким, это совершенно разные технологии.
wi-fi, слава богу, может работать не в прямой видимости, проникает сквозь стены и препятствия, и подальше нескольких метров бьёт.
так точно, скачал все блоки и начал генерировать.
на незагруженном сервере скорость генерации такова, что для создания одного блока нужно «287 days, 4 hours, 42 minutes».
пожалуй, действительно нужен датацентр =)
1. mod_rewrite есть не везде
2. где он есть — очень часто бывает отключен. включить его, даже из панели управления хостингом, среднестатистическому пользователю CMS — маленький подвиг.
3. для пользователя интструкция «добавить вот эту простую строку в любое место файла» гораздо понятнее аналога для mod_rewrite
4. mod_rewrite может активно использоваться на сайте для SEO, например, при этом придётся внедрять обработку 404 в существующие правила. либо наоборот, настроена обработка 404 через mod_rewrite, и нужно внести несколько правил для SEO — просто скопировав правила из инстуркций в интернете (а так все и делают, поверьте) юзер всё разломает.
сразу скажу единственный известный мне минус: апач не умеет отключать нотификацию в error_log о том, что файл не найден, при срабатывании ErrorDocument 404. получаем по одной записи в error_log для каждого срабатывания. есть патчи, отключающие это, но на shared их естественно вам никто не поставит.
Я у ErrorDocument по сравнению с mod_rewrite вижу несколько плюсов и только один минус. Так что, похоже, он будет жить ещё долго =)
Но как только речь зайдёт о расширении, вы сядете в лужу. Другой движок в другом каталоге? Не смешно. В усложнённом проекте нужна унификация, нужен полный контроль за роутингом, итп. Возможно, это будет сюрпризом, но как раз здесь и реализован KISS ;)
надеюсь, что к тому времени вы ещё не успеете написать много кода =))
ошибка автора в том, что он сравнивает свой наколенный подход с крупными коробочными CMS, применительно к которым роутинг через файловую систему слегка отдаёт сумасшедшинкой.
Есть технология, которая действительно называется WiDi (она же Wireless HD). Там идет реалтайм поток без сжатия, можно в игры играть.
Вот, например, телевизор, который умеет нормальный WiDi:
www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?partNumber=KDL52XBR10&catalogId=10551&storeId=10151&langId=-1#overview
Там никакого сжатия, передача fullhd без потерь, и естественно не используется WiFi, пропускная, как я уже говорил, 4Gbps.
wi-fi, слава богу, может работать не в прямой видимости, проникает сквозь стены и препятствия, и подальше нескольких метров бьёт.
ну, надеюсь, и индукционные полы на нашем веку будут =)
на незагруженном сервере скорость генерации такова, что для создания одного блока нужно «287 days, 4 hours, 42 minutes».
пожалуй, действительно нужен датацентр =)