Вот только всё равно не улавливаю проблемы в надобности во введении обратного слеша в DOS, в то время, как весь остальной мир вводил прямые слеши или двоеточия :)
В винде дофига символов запрещены. От двоточия и кавычек до "<" или ">".
При чём, самое интересное, NTFS с ними прекрасно работает. Например, если создать файл «Terminator: The Future Shock», то Windows потом в этот каталог заходит нормально :) Правда, удалить его нельзя…
…
На самом деле под виндой больше всего именно двоеточия не хватает. Очень уж часто оно в названиях фильмов, игр, книг фигурирует…
Всё равно непонятно. В Linux, скажем, ключи традиционно начинаются или с "-", или с "/". Но конфликтов ни со слешами в путях, ни с минусами в именах нет :)
Равно как и в массе DOS-программ понимались ключи с минусом. И этот же минус не был недопустимым символов.
В общем, надуманное какое-то объяснение.
И, самое интересное, 15-20 лет назад, когда процветала MS-DOS, про него почему-то никто не слышал ;)
1. Подобные облака можно иногда увидеть даже вокруг совершенно дозвуковых самолётов.
2. В случае сверхзвука скачок оплотнения, если мне не изменяет память, направлен вперёд. Так что конус будет расходиться не назад, а вперёд.
3. Есть серия подобных видео, где облако появляется рядом с самолётом, летящим буквально в сотнях метров от наблюдателей. Будь это сверхзвук — они бы получили тяжёлые контузии. Кроме того, это облако быстро то появляется, то исчезает периодически. Изменения влажности этот феномен объясняют, а от сверхзвук — нет :) Кстати, по качественным видео можно нередко скорость измерить. На одном из таких я получил около 800км/ч :)
4. Наконец, самолёт не преодолевает звуковой барьер как некое точечное явление, чтобы можно было выделить чёткий момент для формирования подобного облака. Разная геометрия и разное обтекание элементов конструкции приводят к тому, что во многих местах местная скорость потока превышает звуковую уже на 900км/ч, а на некоторых остаётся дозвуковой и после того, как путевая скорость самолёта станет сверхзвуковой. Поэтому скорость самолёта относительно воздуха не является точной величиной.
У меня знакомый однажды на 1700км/ч катапультировался. Правда, там 17км высоты было… Но всё равно ощущения представить можно немного :)
…
Было бы интересно, если бы они гайку на скорости 16км/с в машину вогнали. Т.е. 57600км/ч. Можно бы было б воочую увидеть, что станет со спутником на орбите в такой ситуации :)
Раньше в онлайне фоносемантический анализатор был на analizfamilii.ru, но сейчас стал платным. Среди десятков прочих признаков, так фигурировал и признак округлости/прямолинейности :)
…
Эти параметры легко измеряются не на слух, а точным подсчётом :)
Угу. И где хранить, например, заголовок безбэкендового класса, состоящего из одного шаблона? Организовывать фейковый бэкенд для одних заголовоков? Жирно будет :D
>На хостингах mb_string присутствует практически всегда.
Это не так.
>Я вообще не знаю сегодня ни одного хостера без mb_string или без PHP 5.x
Даже PHP4 Only есть до сих пор. Хотя вот от них я отказался строго — поддержка PHP4 обходится несравнимо дороже. А вот хостинги без mbstring — не редкость.
Вот прямо таки все СУБД и сразу всюду корректно работают? Поддержка UTF-8 может быть вообще не вкомпилена даже в банальный mysql. Если поддержка этой кодировки есть у вас и у меня, это ещё не обозначает, то она будет на любом сервере. Увы, я и сегодня нередко такое встречаю на практике.
2. Если же это что-то типа унифицированного по примеру ранее /parts/posts/2009/04/03/3/20/xxx/ — то тупо передавать 2009/04/03/3/20/xxx внутрь класса parts_posts и пусть он сам разбирается, что с этим форматом делать. list($year, $month, $day, $page, $per_page) = explode('/', $id);
>кверистринг «статическому кэшированию» тоже как бы не особо мешает
Мешает абсолютно :)
/section/?action=list
и
/section/?action=new
будут указывать на один файл.
>пользователь тыкает на ссылки, а вот с урлами приходится возиться программисту.
Ну, это очень трудно догадаться, что класс, обрабатывающий /section/list/ надо искать в classes/section/list.php, а /section/new/ в classes/section/new.php :)
Да, естественно, что каждый тип — свой хэндлер и свой маппинг.
Но я не представляю себе проект, где будут сотни разных типов объектов :)
У меня в самых толстых проектах не бывало больше нескольких десятков типов объектов.
И в любом случае смотреть надо не на абсолютные, а на относительные цифры. Даже в случае, когда объект состоит из десятка строк кода и десятка строк шаблона, одна строка привязки — это ничтожно :) А уж когда объект ещё более сложный…
Наконец — объекты _в любом_ случае нужно как-то привязывать к ссылкам. Так почему бы в этой привязке сразу же и механизм постраничного разбиения не указать?
Вот только всё равно не улавливаю проблемы в надобности во введении обратного слеша в DOS, в то время, как весь остальной мир вводил прямые слеши или двоеточия :)
Тем более, что можно запустить кусок побольше, чтобы к моменту контакта обгорел бы до размеров гайки.
При чём, самое интересное, NTFS с ними прекрасно работает. Например, если создать файл «Terminator: The Future Shock», то Windows потом в этот каталог заходит нормально :) Правда, удалить его нельзя…
…
На самом деле под виндой больше всего именно двоеточия не хватает. Очень уж часто оно в названиях фильмов, игр, книг фигурирует…
Равно как и в массе DOS-программ понимались ключи с минусом. И этот же минус не был недопустимым символов.
В общем, надуманное какое-то объяснение.
И, самое интересное, 15-20 лет назад, когда процветала MS-DOS, про него почему-то никто не слышал ;)
1. Подобные облака можно иногда увидеть даже вокруг совершенно дозвуковых самолётов.
2. В случае сверхзвука скачок оплотнения, если мне не изменяет память, направлен вперёд. Так что конус будет расходиться не назад, а вперёд.
3. Есть серия подобных видео, где облако появляется рядом с самолётом, летящим буквально в сотнях метров от наблюдателей. Будь это сверхзвук — они бы получили тяжёлые контузии. Кроме того, это облако быстро то появляется, то исчезает периодически. Изменения влажности этот феномен объясняют, а от сверхзвук — нет :) Кстати, по качественным видео можно нередко скорость измерить. На одном из таких я получил около 800км/ч :)
4. Наконец, самолёт не преодолевает звуковой барьер как некое точечное явление, чтобы можно было выделить чёткий момент для формирования подобного облака. Разная геометрия и разное обтекание элементов конструкции приводят к тому, что во многих местах местная скорость потока превышает звуковую уже на 900км/ч, а на некоторых остаётся дозвуковой и после того, как путевая скорость самолёта станет сверхзвуковой. Поэтому скорость самолёта относительно воздуха не является точной величиной.
…
Было бы интересно, если бы они гайку на скорости 16км/с в машину вогнали. Т.е. 57600км/ч. Можно бы было б воочую увидеть, что станет со спутником на орбите в такой ситуации :)
Раньше в онлайне фоносемантический анализатор был на analizfamilii.ru, но сейчас стал платным. Среди десятков прочих признаков, так фигурировал и признак округлости/прямолинейности :)
…
Эти параметры легко измеряются не на слух, а точным подсчётом :)
Один проект делаю, поскольку зарабатываю на его внедрениях. Но при этом исходники свободно раздаю по GPL.
Пара других проектов — просто Just For Fun.
Ну а свои патчи и багрепорты за участие в опенсорс не считаю ;)
Угу. И где хранить, например, заголовок безбэкендового класса, состоящего из одного шаблона? Организовывать фейковый бэкенд для одних заголовоков? Жирно будет :D
Это не так.
>Я вообще не знаю сегодня ни одного хостера без mb_string или без PHP 5.x
Даже PHP4 Only есть до сих пор. Хотя вот от них я отказался строго — поддержка PHP4 обходится несравнимо дороже. А вот хостинги без mbstring — не редкость.
А зачем когда единая точка входа во фреймворк во всех смыслах удобнее?
>а вот что-нить по сложнее: /posts/2009/04/03/3/20/xxx/
1. А это уже сразу по формату видно, что уникальный, а не типичный случай. Его мапить отдельно
'/posts/(\d{4}/\d{2}/\d{2}/\d+/\d+)/ => my_handler($1)'
2. Если же это что-то типа унифицированного по примеру ранее /parts/posts/2009/04/03/3/20/xxx/ — то тупо передавать 2009/04/03/3/20/xxx внутрь класса parts_posts и пусть он сам разбирается, что с этим форматом делать. list($year, $month, $day, $page, $per_page) = explode('/', $id);
Мешает абсолютно :)
/section/?action=list
и
/section/?action=new
будут указывать на один файл.
>пользователь тыкает на ссылки, а вот с урлами приходится возиться программисту.
Ну, это очень трудно догадаться, что класс, обрабатывающий /section/list/ надо искать в classes/section/list.php, а /section/new/ в classes/section/new.php :)
Я же привёл пример, как одним реврайтом и одним мапингом мы можем прописать любое количество хэндлеров.
И мой пример кроме формата URL (более человекопонятного) [i]от твоего ничем не отличается[/i] :)
>затем, чтобы по урлу было видно либо он роутится на хэндлер, либо нет
В формате URL лучше ориентироваться на пользователя, а не на программиста.
>а зачем делать псевдостатику
Например, затем, что она позволяет включить статическое кеширование, которое сразу на пару-тройку порядков повысит производительность сервера :)
>и потом ковыряться в конфликтах между реврайтами и реальными файлами?
А их и нет в моём случае.
>почему бы не использовать единое правило роутинга для всех хэндлеров? я, например, параметры передаю так: d-o-b.ru/?article:hiqus
Так для такого случая мой метод точно также работает, как и для каждой отдельной прописи.
'/sections/(\w+)/(\d+)\.html => sections_loader($1, $2)',
А внутри sections_loader:
function pre_action() { $handler = object_loader('prefix_'.$this->id()); $handler->set_page($this->page()); return $handler; }
>при этом глядя на ссылку я чётко понимаю какой файл вызывается и нет необходимости мысленно матчить реврайты…
Ну, у меня обычно реврайт вообще только один. Если нет такого статического файла — то на общий лоадер :)
И, вообще, я не понимаю, зачем нужны ссылки вида ?article/list, если можно сразу вызывать /article/list/ :)
Но я не представляю себе проект, где будут сотни разных типов объектов :)
У меня в самых толстых проектах не бывало больше нескольких десятков типов объектов.
И в любом случае смотреть надо не на абсолютные, а на относительные цифры. Даже в случае, когда объект состоит из десятка строк кода и десятка строк шаблона, одна строка привязки — это ничтожно :) А уж когда объект ещё более сложный…
Наконец — объекты _в любом_ случае нужно как-то привязывать к ссылкам. Так почему бы в этой привязке сразу же и механизм постраничного разбиения не указать?
'/section/ => my_section_handler',
появляется или две:
'/section/ => my_section_handler',
'/section/(\d+)\.html => my_section_handler($1)',
или одна:
'/section/((\d+)\.html)? => my_section_handler($2)',
где тут сотня (лишних) маппингов?