За последние 24 часа нас посетили 20293 программиста и 1095 роботов. Сейчас ищут 348 программистов ...

Готовое решение: PHPC — PHP Compiler CMF

Тема в разделе "Решения, алгоритмы", создана пользователем Dagdamor, 2 мар 2007.

  1. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Namer
    Самое дурацкое, что в меню Настроек эту функцию никак не включить, нужно именно лезть в INI файл. :/
    А вот в 7-й версии Оперы такая настройка - есть. Собственно, оттуда я ее название и позаимствовал :)
     
  2. Namer

    Namer Активный пользователь

    С нами с:
    14 апр 2010
    Сообщения:
    492
    Симпатии:
    0
    Не, не обязательно! :) У Оперы настройки быстро и легко менять можно прямо в окне браузера. Достаточно в адресной строке ввести opera:config Я этим способом поменял (естественно ориентировался на ваш указатель [User Prefs]=>Trust Server Types=1)
     
  3. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    Namer
    О! Действительно! Спасибо за наводку :)
     
  4. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    > неужели для того, чтобы отобразить 5 простых страниц, обязательно необходим XSL из 600 строк и CSS из 500

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

    > Чесслово, все то же самое у меня делается намного, намного проще и красивее.

    покажи.

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

    зачем ты используешь курл, если можно просто file_get_contents?
     
  5. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    tenshi
    www.phpc.ru/files/samples/phpcvsxslt/phpc.zip

    Но учтите, пример был собран на коленке и наспех, скорее всего, там можно еще многое соптимизировать. Обратите внимание на шаблон menu (это та самая менюха, которую вы "генерируете" через heredoc):

    HTML:
    1. <insert:htmlMenu>
    2.   <insert:htmlMenuItem link="/" title="Читай"/>
    3.   <insert:htmlMenuItem link="/gallery" title="Смотри"/>
    4.   <insert:htmlMenuItem link="/tracks" title="Слушай"/>
    5. </insert:htmlMenu>
    Чуть удобнее вашего формата, не правда ли :)

    И еще обратите внимание на размер моего конечного HTML-файла (около 3 Кб). Сравните со своей связкой (XML+XSLT+CSS, в сумме почти 30 Кб). К тому же мой вариант не требует поддержки XSLT, да и вообще заметно опрятнее.

    У меня под виндой file_get_contents ведет себя как-то странно - HTTP-запросы работают ОЧЕНЬ медленно, гораздо медленнее, чем отрабатывает PHP-скрипт. Видимо, там что-то постоянно соединяется/отключается на каждый вызов. Через курл - намного быстрее, причем выполняется именно требуемое количество запросов (проверял), и результат замера оказывается близок к фактическому времени работы скрипта.

    Дык вы же ее сваливаете на клиента. Предлагаете сравнивать мой шаблонизатор с пустым местом? ;)
    А если в вашем примере включить серверный шаблонизатор, движок сразу замедляется раз в десять.

    Структуру базы я скопировал один-в-один - только добавил поле id, ну не могу я видеть PRIMARY KEY по строке ;). Поэтому выборка статей для главной у меня делается точно таким же лайком (см. шаблон index). Но вот что и впрямь могло повлиять в пользу моего движка - у вас база в УТФ, а я свою сделал в cp1251. Иных причин, почему MySQL оказался быстрее SQLite, я не вижу. ;)
     
  6. Namer

    Namer Активный пользователь

    С нами с:
    14 апр 2010
    Сообщения:
    492
    Симпатии:
    0
    Dagdamor, а можно абсолютно весь сайт запихнуть в phpc, со всеми файлами и картинками? Сайтик небольшой, на html и уже готов. Я хотел это сделать для того, чтобы абсолютно все запрашиваемые файлы отдавать скриптом и собирать статистику заголовков пользователей для изучения и понимания картины посещений.
     
  7. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    через хередок выводятся только фатальные ошибки. для остальных страниц меню задаётся массивом в data/page.php где хранится базовая структура страницы

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

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

    именно так. для пользователя разница незаметна, для сервера она существенна.

    а вот это капец. иероглифы ты как хранишь? хтмл-сущностями чтоли?

    в sqlite оно есть всегда
     
  8. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    и так, приступим к установке твоего движка
    я его распаковал, и получил "Фатальная ошибка PHPC: Невозможно подключиться к БД."
    замечательно, и что делать теперь? хоть бы ссылку добавил бы, на страничку где бы было расписано как настраивать подключение к базе. а лучще, чтобы как в нормальных движках - запускается конфигуратор, в котором можно произвести основные настройки без лазания по исходникам
     
  9. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    tenshi
    ты на свои тесты лучше посмотри, которые по производительности ;) а потом будешь ему чё то тыкать...
     
  10. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    прогнал тесты..

    Тестируемый URL: http://phpc/.
    Количество запросов: 100.
    Время работы: 8.281.
    Среднее время одного запроса: 0.083.

    Тестируемый URL: http://smilegx/?article/list.
    Количество запросов: 100.
    Время работы: 1.652.
    Среднее время одного запроса: 0.017.
     
  11. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    у меня в этой версии движка нет поддержки кэширования и серверного наложения. ты как реализовал серверное наложение? случаем не пытаешься курлом получать скомпилированный хслт? х)
     
  12. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    впрочем, вот, нашёл формирование рсс:

    Тестируемый URL: http://smilegx/?rss/article/list.
    Количество запросов: 100.
    Время работы: 4.138.
    Среднее время одного запроса: 0.041.

    как он формируется: делается внутренний запрос к ?article/list который возвращает xml, потом запрос к ?xsl:rss который собирает все шаблоны в один файл (и всё это без кэширования, надо заметить), ну и, наконец, производит трансформацию и возвращает полученный фид.
     
  13. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    ой, вру, это с ?xsl:main вместо ?xsl:rss

    а с ?xsl:rss ещё быстрее:

    Тестируемый URL: http://smilegx/?rss/article/list.
    Количество запросов: 100.
    Время работы: 2.541.
    Среднее время одного запроса: 0.025.
     
  14. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    а вот тут я положил скомпилированную xsl-ину в файл и загружаю из него:

    Тестируемый URL: http://smilegx/?rss/article/list.
    Количество запросов: 100.
    Время работы: 2.693.
    Среднее время одного запроса: 0.027.
     
  15. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    давай сверим версии:
    PHP Version 5.2.5
    mysqli 5.0.45
    mysql Ver 14.14 Distrib 6.0.6-alpha, for Win32 (ia32)
    SQLite Library 3.3.17undefined
    libxslt Version 1.1.17
    libxml Version 2.6.26
    ось - win7
     
  16. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    tenshi
    Я чего-то в этом роде ожидал. ;) Магическим образом XSLT вариант начал работать аж в пять раз быстрее...
    Ладно, подождем кого-нибудь еще, кто запустит у себя оба примера и выложит свой вариант.

    Нет, конечно. Я сохранил один раз готовый XSLT (см. архив xslt.zip, ссылку я выкладывал выше), его и скармливал процессору. Код взял из RSS файла, да, но XSLT у меня подгружался как обычный файл.

    Остальные твои тесты вызывают у меня здоровый скептицизм... вот смотри, главная страница со сборкой у клиента (линк) у тебя отработала за 0.017 сек. Та же главная, но со сборкой на сервере (линк), отработала за 0.027 сек. Со сборкой на сервере! Это плюс подгрузка XSLT файла, потом наложение XSLT на XML (а это парсинг сначала XML и формирование DOM, потом парсинг объемного XSLT, множественные преобразования XML, наконец, сборка результата обратно в текст)... и якобы всего лишь в полтора раза медленнее, хотя объем работы вырос в два-три раза. Я должен этому поверить? ;)

    И я никогда не поверю, что у тебя PHPC "вдруг" стал работать в разы медленнее твоего примера, в то время как у меня скорость работы практически одинаковая.

    В общем, подождем цифр от человека незаинтересованного.
     
  17. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    tenshi
    Разве?
    smilegx/branch/cssing/index.php:
    PHP:
    1. <?php
    2.  
    3. return <<<XML
    4. <?xml version="1.0" encoding="utf-8" ?>
    5. <?xml-stylesheet type="text/xsl" href="?xsl:main" ?>
    6. <o:data
    7.     xmlns="http://www.w3.org/1999/xhtml"
    8.     xmlns:h="http://www.w3.org/1999/xhtml"
    9.     xmlns:o="http://d-o-b.ru/iface/#smileg"
    10.     >
    11. <o:section-list>
    12.     <o:section>
    13.         <o:uri>?article/list</o:uri>
    14.         <o:title>Читай</o:title>
    15.     </o:section>
    16.     <o:section>
    17.         <o:uri>?galery</o:uri>
    18.         <o:title>Смотри</o:title>
    19.     </o:section>
    20.     <o:section>
    21.         <o:uri>?track/list</o:uri>
    22.         <o:title>Слушай</o:title>
    23.     </o:section>
    24. </o:section-list>
    25. <o:error>
    26.     <o:message>{$buffer}</o:message>
    27. </o:error>
    28. </o:data>
    29. XML;
    А кто сказал, что у меня теги использовать нельзя? Если нужно - то на здоровье. Значения переменных в PHPC экранируются по умолчанию, учите матчасть. ;) Это мой формат является расширяемым, ибо, например, впридачу к htmlMenuItem можно написать htmlMenuGroup (добавив соответствующий шаблон разумеется), в нем - вложенные htmlMenuGroup и htmlMenuItem, построив таким образом древовидное меню, любой вложенности, любой сложности. Вот это и есть настоящая расширяемость, а не "HTML-теги в тексте". У вас такое организовать - нереально. Ну добавите вы элементов в heredoc (даже это потребует в разы более объемной писанины, сравните синтаксис там и там), а дальше что. Корректно обработать это стайлшитом будет уже нереально - предлагаю попробовать. Мой работающий пример - вот.

    А вот и нет. У меня шаблоны структурированы и организованы так, чтобы каждый был простым и понятным. Растет проект - сложность поддержки не увеличивается, ибо держать все шаблоны в уме незачем - они не влияют друг на друга. А вот у вас - наоборот. Чем сложнее проект, тем больше однообразных XSLT-правил, и начиная с некоторого момента, их становится нереально понимать и поддерживать. Мне понадобилось несколько дней, чтобы въехать в ваши десятки и сотни XSLT-мутаторов (каждый из которых абсолютно "неговорящ", и что он делает - сходу не сообразить). Уверен, вам хватило пяти минут, чтобы разобраться с моими шаблонами.

    Понадобится добавить что-то новое на сайт (каменты например), со своим оформлением - тут же придется писать новые правила преобразования, новые стили, новые вьюхи... какая же это константа? XSLT не волшебная палочка, объем и сложность стайлшитов точно так же зависит от сложности задания. И по мере того, как сайт усложняется, усложняются и ваши "шаблоны". На пять страниц вы наколбасили 30 Кб шаблонов и стилей. Соответственно, на 10 страниц понадобится 60 Кб, и никуда от этого вы не денетесь.

    Какой кошмар o_O

    Это по желанию. Можно запихнуть, можно в отдельный файл. Мой движок тут не выдвигает требований.

    То есть вы в начале своей темы (xstyle) сравнивали шаблонизатор Смарти с пустым местом у вас, делали вывод, что Смарти медленнее пустого места, и этим гордились? Невелика заслуга.

    Да. PHPC их поддерживает прозрачно (например, не трогает при экранировании данных). В вашем дампе "иероглиф" был всего в одном месте базы - переводить из-за одной-единственной каракули весь дамп в УТФ как-то неумно.

    Не знаю, есть оно или не есть, но при экспорте никаких ID в дампе не было. А первичный ключ был навешен на текстовые поля типа "url" (тоже, конечно, надо было додуматься до такого, хотя ладно, мы не об этом).
     
  18. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    переменная buffer содержит вывод текста ошибок. экшены же выводят данные через структуру response, которая отдаётся http принтеру, который и формирует окончательный вывод браузеру. если в процессе работы возникают ошибки, то они попадают в буфер и он выводится через костыль который работает даже в случае нехватки памяти в обход всяких принтеров.

    потому что для экономии байтов ты засунул значения в атрибуты.

    x)
    PHP:
    1. return $this->cache= array(
    2.     'section-list' => array(
    3.         array(
    4.             'uri' => '?article/list',
    5.             'title' => 'Читай',
    6.             'subsection-list' => array(
    7.                 array(
    8.                     'uri' => '?articl/list/tag:client-side',
    9.                     'title' => 'Про клиентов',
    10.                 ),
    11.                 array(
    12.                     'uri' => '?articl/list/tag:server-side',
    13.                     'title' => 'Про серветов',
    14.                 ),
    15.                 array(
    16.                     'uri' => '?articl/list/tag:protocol',
    17.                     'title' => 'Про протоколы',
    18.                 ),
    19.             )
    20.         ),
    21.         array(
    22.             'uri' => '?galery',
    23.             'title' => 'Смотри',
    24.         ),
    25.         array(
    26.             'uri' => '?track/list',
    27.             'title' => 'Слушай',
    28.         ),
    29. ...
    при этом мне достаточно просто добавить данные для выпадающего меню, а тебе придётся меня имена тэгов для меню с insert:htmlMenuItem на insert:htmlMenuGroup
     
  19. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    при смешивании логики и вёрстки сложность растёт экспоненциально ибо за логикой размазанной по шаблону очень сложно следить.
    а у меня шаблоны тоже не влияют друг на друга.

    это с непривычки. и то, ты так и не въехал судя по вопросам. у тебя предвзятое отношение, поэтому ты вместо того, чтобы понять идею выдаёшь её отличия от того, к чему ты привык, за недостатки. и что за xslt-мутаторы? если ты про кастомные тэги, разделяющие вёрстку на 3 взаимопроникающих слоя слоя (данные, стилизация, поведение) из исходно одного слоя сданными, то ни к xslt, ни к какому-либо другому шаблонизатору это не имеет никакого отношения. разве что на xslt это реализовать проще.
     
  20. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    всё зависит от степени отличия этих 5 страниц о уже существующих. впрочем, сложность измеряется не в килобайтах а в количестве логических блоков. у меня это количество пропорционально количеству уникальных блоков на всех страницах. у тебя это число умножается на число страниц.
    нет, смарти я сравнивал с серверным наложением, чтобы показать, что даже в худшем случае xslt быстрее smarty.
     
  21. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    какие весёлые костыли х) а имейлы ты как формируешь? а рсс? а сообщения в джаббер? в общем, сочувствую я тому кто будет использовать твой движок - постоянные косяки с кодировками обеспечены.

    разумеется не было. это неявное поле с именем ROWID

    и что в этом плохого? у меня везде поиск осуществляется по человеко-понятным идентификаторам, а не по непонятным циферкам
     
  22. Padaboo

    Padaboo Старожил
    Команда форума Модератор

    С нами с:
    26 окт 2009
    Сообщения:
    5.242
    Симпатии:
    1
  23. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    с чего ты взял что в 2-3 раза? данные получаются из базы, передаваясь через тучу магических методов, потом сериализуются в хмл-строку. это не сильно меньше парсинга 2 хмл-ек, наложения хслт и сериализаций в хмл выполняемой целиком и полностью сишными библиотеками. в боевом окружении с удалённой и большой базой разница будет ещё меньше.
     
  24. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    tenshi
    То есть если то же самое, но по-русски: сделать как надо и хранить главное меню в одном-единственном месте системы не получилось.

    И что? Повторяю вопрос: кто сказал, что у меня нельзя использовать теги в меню? ;)

    И? Ну добавили вы еще один атрибут в свою структру, а что толку? Уверяю, работать оно не будет. Надо соответствующим образом изменять XSLT правила, как минимум добавлять обработку <o:subsection-list>, иначе он по умолчанию так и выведется соплей на странице. Вы попробуйте это сделать сначала, чтобы оно работало, а потом уж хвастайтесь. То, что у меня для вложенных групп надо использовать другой тег - это на самом деле плюс, а не минус. Так шаблон "menu" выглядит намного нагляднее мешанины из тегов одного типа. И напоследок - сравните ваш кошмарный синтаксис (что PHP, что XML), и мой - предельно простой и удобный. :)

    Ну так не размазывайте логику по шаблону. Сделайте себе удобный набор вспомогательных шаблонов, которые о логике ничего не знают, и которые занимаются только выводом и оформлением - сколь угодно сложным - а логику оставьте для основного шаблона, который будет вызывать вспомогательные. Вот вам и отделение логики от представления. Типичный пример этого подхода на PHPC:
    Код (Text):
    1. <insert:htmlArticlesList>
    2.  
    3. <logic:iterator property=articles item="article">
    4.   <insert:htmlArticle article=article/>
    5. </logic:iterator>
    6.  
    7. </insert:htmlArticlesList>
    Логика - здесь. Оформление - во вспомогательных шаблонах, и оно может быть сколь угодно навороченным, основному шаблону нет до этого дела. Нужно изменить логику - смотрим основной шаблон. Нужно изменить оформление - смотрим вспомогательные. Предельно просто и удобно. Как такую же красоту сделать в XSLT, где все в одной куче, а детали оформления размазаны по десяткам правил типа
    Код (Text):
    1. <t:template match=" /o:data/o:track-list/o:track/o:descr ">
    2.     <p>
    3.         <t:call-template name="copy-n-apply"/>
    4.     </p>
    5. </t:template>
    ? Я не знаю.

    В конечном счете - все равно в килобайтах :) У вас это количество пропорционально не количеству блоков, а количеству комбинаций между ними по вложенности - см. пример вашего кода выше. Для пути "/o:data/o:track-list/o:track/o:descr" у вас один фрагмент кода. Для пути "/o:data/o:track-list/o:descr/o:track" у вас другой. Для пути "/o:data/o:descr/o:track-list/o:track" у вас третий, и так далее. И все это - копипаста, копипаста, копипаста.

    У меня объем писанины в шаблонах пропорционален их количеству, т.к. я стараюсь все шаблоны оставлять небольшими, чтобы можно было понять каждый с одного взгляда. А количество шаблонов, в свою очередь, пропорционально количеству различных элементов дизайна на сайте - таблица, форма, галерея и т. д. Да, разумеется, с усложнением проекта у меня растет количество шаблонов. Но зависимость скорее обратная - чем больше страниц, чем больше вероятность, что для новой страницы хватит уже имеющегося набора вспомогательных шаблонов. Они ведь как инструментарий - однажды накопленный, он уже почти не растет.

    Дык а в чем разница-то? Страница - это HTML. RSS - это XML (тот же HTML, только сбоку). Письмо - тот же HTML текст. Везде такие символы прекрасно работают. Вопрос: если с точки зрения HTML/XML юникод-символ и html-последовательность являются взаимозаменяемыми, в чем разница конечному посетителю?

    Хех! Уже, наверное, с сотню проектов подняли на моем движке - пока ни одной жалобы на проблемы с кодировками ^_^
    Сравните это с количеством воплей "у меня ?????? вместо букав че делать???" здесь, сравните это с откровенно уродской "поддержкой" UTF-8 в том же SQLite. Вы, надеюсь, в курсе, что полноценно сравнивать UTF8-строки, равно как и проверять корректность входящих UTF8-данных, SQLite до сих пор не умеет? ;)

    То, что на моем движке, например, принят другой предпочтительный стандарт для "красивых" URL-ов. Никаких "?", ":" и прочей порнографии там нет, запросы имеют вид /catalog/russian/auto/bmv18. Соответственно, ваш дамп без муторной переделки уже не годится для использования в другой системе. А сделали бы, как все люди, линки между таблицами через целочисленные поля - все было бы намного проще.
     
  25. tenshi

    tenshi Активный пользователь

    С нами с:
    1 июн 2010
    Сообщения:
    191
    Симпатии:
    0
    да, мне очень хотелось перехватывать все фатальные ошибки, не оставляя пользователя с белым экраном. ради этого пришлось пойти на некоторые жертвы.

    ковыряться в экранированном хмл-е - то ещё удовольствие. тебе нужно пренепременно меня переспорить или ты всё так абы как делаешь?

    а у тебя обработка групп возьмётся из астрала чтоли?

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

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

    остапа понесло.. нету там такого бессмысленного жонглирования именами.

    ни хмл, ни плейнтекстовые письма не понимают хтмл-сущности

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

    ты так говоришь как будто в 1251 он внезапно начинает поддерживать нечувствительность к регистру.

    ты привязываешься к строго деревянной иерархии и геморроишься с "красивыми" урлами разруливая тучу реврайтов. я же занимаюсь более интересными вещами не привязываясь к иерархии. ты читал статью про урлы?

    не было бы. на вход из урла приходит текстовый идентификатор. какой смысл искать по нему численный, чтобы потом сделать выборку по численному?