Все же не совсем уже инновационное это решение. Убунту изобрела Enso (приложение под Win, разработанное в компании сына небезызвестного Раскина) humanized.com/enso/
Другое дело, что это будет первой массово используемой (ну или по крайней мере известной) фичей подобного рода.
А можете озвучить ради интереса эти плюсы? Мне как-то ближе mod_rewrite в том плане, что ErrorDocument это все-таки обработка ошибки в первую очередь. Но хотелось бы услышать альтернативное мнение по этому поводу.
у меня роутинг через FS решился одной маааленькой функцией (15 строк), которая создает php-файл буквально из 3 строк (+ доп. параметры, если нужны, чтобы не ходить за ними в БД). При занесении новой записи через админку файл автоматом генерится (+1 строчка в исходнике) и при удалении записи соответственно удаляется файл (еще +1 строчка). Такая система работает уже лет 6.
Для действительно крупных проектов, конечно, с таким подходом иногда могут возникать неудобства при разработке (хотя и все зависит от конкретной реализации, архитектуры системы и структуры сайта). Но как правило проекты такой величины разрабатываются либо на сильно кастомизированной CMS, либо под них система с нуля пишется.
В случае каталога продукции разницы не ощущается — либо разбирать урл и писать роутинг, либо в момент создания/редактирования/удаления записей вызывать одну функцию, которая сгенерирует файл с одним инклудом и несколькими параметрами (которые в случае mod_rewrite мы получаем именно через разбор URL'а и обращения к БД).
У меня лично проблема возникла, когда на одном из собственных проектов понадобилось создать по странице на каждый город мира с хоть сколько-нибудь значительным населением. Начался адъ, когда решил откопировать директорию проекта на локальной машинке (несколько десятков тысяч маленьких индексных файлов).
Уйти от такой схемы более чем просто — много кода менять не приходится.
Моя старенькая CMS (которая до сих пор используется, многое допилено, но этот момент тянется уже много лет из версии в версию), расчитанной на небольшие проекты, обходилась без htaccess и mod_rewrite впринципе. На каждый раздел сайта или страницу внутри раздела создается свой index.php (имя может быть другое, если нужно), который подключает движок. Помимо непосредственно подключения системы этот индексный файл может содержать какие-то дополнительные параметры для модулей (например, id записи, которая должна находится по данному пути, действие, которое необходимо выполнить и т. д.).
В итоге система получает только те запросы, которые действительно должна обрабатывать (т. е. только запросы страниц сайта, созданных через CMS) и без оверхеда на подзапросы (хотя этим можно принебречь). На отдачу статики не влияет. А если по запрошенному URL ничего нет — отдается обычная 404, сгенерированная самим сервером без помощи скриптов.
Разрешение — 1024. Если вычесть ширину полосы прокрутки выйдет 1000 (вроде даже 1004) пикселя. 980 — это разве что для тех, у кого полоса прокрутки больше стандартной :-)
Справедливости ради, стоит заметить, что is_ajax — это проверка вполне конкретного заголовка на равенство константе.
Когда я говорил про тернарный оператор, я говорил об отсутствии необходимости функции вроде get($name, $default), где необходимо передать индекс возвращаемого элемента массива. В случае is_ajax этого не требуется. Если бы в реализации is_ajax использовался бы подобный геттер (а он используется), я бы посчитал излишней такую реализацию, но не наличие самой функции. Сама функция является удобной — это не абстрактное «возьми переменную из массива», а все же вполне конкретное «запрос через ajax пришел?».
> Вы ведь этот фреймворк не смотрели и не собираетесь, да и наверное никакой другой тоже.
Представьте себе, смотрел еще как. Фреймворк полон тривиальных вещей. Единственное удобство во всем фреймворке — is_ajax(). Да, тривиальная штука, но удобная. Да, есть везде и пишется за насколько секунд, но написать is_ajax куда проще, чем проверять заголовки.
И да, ORM может быть полезной фичей в ряде задач. Но, как вы сами же сказали, оно здесь не свое-родное, так что не будет приписывать чужие достоинства данному фреймворку. В документации про работу с БД я не нашел соответствующего раздела, поэтому будем считать вопрос работы с БД открытым и этот компонент системы может быть изменен/заменен в будущем — тогда и обсудим его достоинства и недостатки.
> Они ведь преимуществ перед чистым php не дают
Я говорил про данный конкретный фреймворк, а не про любой абстрактный. Не стоит додумывать.
Ок, работа с БД в том виде, который имеется в данном фреймворке — час кодинга.
Маршрутизация тоже далеко не великое изобретение. Она имеется в любом фреймворке. Да и в необходимом для конкретного проекта объеме она реализуется менее чем за день. Если решать вопрос маршрутизации в общем случае, я не представляю как решение, выбранное разработчиками данного фреймворка, можно реализовывать более дня-двух (с учетом того, что нужно еще и подумать, почему делаем именно так, а не иначе).
Итого имеем: никаких преимуществ перед написанием кода на чистом php без использования оберток мы не получаем, если используем FUEL. А судя по организации компонентов, их набору и времени, затраченному на разработку этого чуда, никаких преимуществ и не придвидится.
Фреймворк для тех, кому лень читать доки на php.net, но не лень потратить столько же времени на чтение доков fuel. Как-то так.
«Нового» — я как раз таки и говорил о каком-то дополнительном функционале или удобстве. Здесь и дополнительного нет, и удобного. Сплошные синонимы стандартных функций в чуть другом виде, которая погоды ни при каких условиях не делает.
Обертки над БД по крайней мере реализуют абстракцию от самой БД и при правильной организации позволяют с легкостью сменить используемую БД. Они как раз таки и позволяют прогонять запросы через интерфейс и не задумываться об особенностях БД, чтобы защититься от инъекций или просто отправить запрос и получить данные.
Хорошая реализация обертки либо позволяет сложить с себя часть обязанностей по защите данных и их хранению, либо получить объектное представление записей из реляционной БД, к примеру.
Если вы точно не собираетесь менять БД и пишете какую-то служебную утилитку для работы с mysql, часто достаточно mysqli_*-функций.
Если вам нужно объектное отражение записей — вы используете обертку.
Если вам нужна доп. обработка запросов и данных из БД — вы опять используете обертку.
Но если вам нужно получить элемент массива $_SERVER, я не понимаю, зачем здесь нужна обертка.
Я пользуюсь тем, что дает мне необходимый функционал, отсутствующий в готовом виде в самом интерпретаторе и его стандартных либах. Но использовать псевдофреймворк, который ничего не добавляет, а лишь увеличивает ресурсоемкость системы и только лишь добавляет синонимы к стандартным функциям, я не считаю целесообразным.
Чтобы использовать header() мне не нужен «фреймворк». Чтобы обратиться к $_COOKIE мне тоже не нужен набор классов и объектов. Другое дело, если помимо непосредственно обращения к переменной или записи значения в массив мне требуется выполнить еще с десяток операций — тогда я уже задумаюсь.
Но предложенный выше «фреймворк» ничего подобного не предоставляет. И судя по тому, что у ребят на написание синонимов 2 месяца ушло, вряд ли в ближайшие годы я смогу считать его чем-то нужным и стоящим.
Здесь вопрос несколько спорный на самом деле. С одной стороны, да, мы скрываем реализацию. С другой стороны сама реализация и логика настолько тривиальна, что фактически ничего мы и не скрываем.
В случае тернарного оператора мы точно так же лишь указываем, что переменная является опциональной. С точки зрения читабельности кода, мне ближе именно вариант с тернарным оператором, чем функция, коих в окружении множество.
header() тоже не сразу отправляет заголовок, а точно так же складывает заголовки в массив. Этот массив можно получить функцией headers_list(). А можно и удалить ненужный заголовок через header_remove(). Итого, имеем тот же набор функций, но минус тонну кода, потому как данные функции родные. А те, что предлагаются фреймворком, лишь перегоняют данные из одного массива в другой.
Собственно _fetch_from_array опять же ничего существенного не дает. Как я уже выше сказал, отлично справится на его месте тот же тернарный оператор. И это ничуть не сложнее.
Прошу прощения, set_header, конечно же, как следует из названия, проставляет заголовок. Увлекся разглядыванием send_headers :-)
Но, посмотрев тот самый исходник, на который вы дали ссылку, я так и не понял, чем разработчиков не устроил стандартный php'шный header().
Мне кажется, для очистки от xss достаточно одной функции наподобие cleanxss($param) вместо набора из пяти функций. Кстати, насчет очистки в документации нет ни слова. Ровно как нет у этого набора функций никаких доп. параметров, которые бы сообщали о необходимости очистки, если она выполняется только при необходимости.
> А если всё равно он используется, то почему бы не воспользоваться его возможностями
А зачем он используется, если не предоставляет ничего нового и дополнительного, а все его возможности изначально заложены в ядро PHP (часто, с более коротким и понятным синтаксисом, более того, известным каждому разработчику, а не только имеющими опыт работы с данным фреймворком). Чтобы воспользоваться теми самыми «уникальными» возможностями, которые и без того имеются?
Кстати, для простановки дефолтных значений, как ни странно, тернарный оператор ничуть не сложнее, чем приведенные выше функции. Зато не заставляет тащить за собой некий «фреймворк».
set_header не принимает аргументов и не возвращает значения, так что установку значения он не производит никак.
И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).
humanized.com/enso/
Другое дело, что это будет первой массово используемой (ну или по крайней мере известной) фичей подобного рода.
Для действительно крупных проектов, конечно, с таким подходом иногда могут возникать неудобства при разработке (хотя и все зависит от конкретной реализации, архитектуры системы и структуры сайта). Но как правило проекты такой величины разрабатываются либо на сильно кастомизированной CMS, либо под них система с нуля пишется.
В случае каталога продукции разницы не ощущается — либо разбирать урл и писать роутинг, либо в момент создания/редактирования/удаления записей вызывать одну функцию, которая сгенерирует файл с одним инклудом и несколькими параметрами (которые в случае mod_rewrite мы получаем именно через разбор URL'а и обращения к БД).
У меня лично проблема возникла, когда на одном из собственных проектов понадобилось создать по странице на каждый город мира с хоть сколько-нибудь значительным населением. Начался адъ, когда решил откопировать директорию проекта на локальной машинке (несколько десятков тысяч маленьких индексных файлов).
Уйти от такой схемы более чем просто — много кода менять не приходится.
В итоге система получает только те запросы, которые действительно должна обрабатывать (т. е. только запросы страниц сайта, созданных через CMS) и без оверхеда на подзапросы (хотя этим можно принебречь). На отдачу статики не влияет. А если по запрошенному URL ничего нет — отдается обычная 404, сгенерированная самим сервером без помощи скриптов.
Когда я говорил про тернарный оператор, я говорил об отсутствии необходимости функции вроде get($name, $default), где необходимо передать индекс возвращаемого элемента массива. В случае is_ajax этого не требуется. Если бы в реализации is_ajax использовался бы подобный геттер (а он используется), я бы посчитал излишней такую реализацию, но не наличие самой функции. Сама функция является удобной — это не абстрактное «возьми переменную из массива», а все же вполне конкретное «запрос через ajax пришел?».
Представьте себе, смотрел еще как. Фреймворк полон тривиальных вещей. Единственное удобство во всем фреймворке — is_ajax(). Да, тривиальная штука, но удобная. Да, есть везде и пишется за насколько секунд, но написать is_ajax куда проще, чем проверять заголовки.
И да, ORM может быть полезной фичей в ряде задач. Но, как вы сами же сказали, оно здесь не свое-родное, так что не будет приписывать чужие достоинства данному фреймворку. В документации про работу с БД я не нашел соответствующего раздела, поэтому будем считать вопрос работы с БД открытым и этот компонент системы может быть изменен/заменен в будущем — тогда и обсудим его достоинства и недостатки.
> Они ведь преимуществ перед чистым php не дают
Я говорил про данный конкретный фреймворк, а не про любой абстрактный. Не стоит додумывать.
Маршрутизация тоже далеко не великое изобретение. Она имеется в любом фреймворке. Да и в необходимом для конкретного проекта объеме она реализуется менее чем за день. Если решать вопрос маршрутизации в общем случае, я не представляю как решение, выбранное разработчиками данного фреймворка, можно реализовывать более дня-двух (с учетом того, что нужно еще и подумать, почему делаем именно так, а не иначе).
Итого имеем: никаких преимуществ перед написанием кода на чистом php без использования оберток мы не получаем, если используем FUEL. А судя по организации компонентов, их набору и времени, затраченному на разработку этого чуда, никаких преимуществ и не придвидится.
Фреймворк для тех, кому лень читать доки на php.net, но не лень потратить столько же времени на чтение доков fuel. Как-то так.
Обертки над БД по крайней мере реализуют абстракцию от самой БД и при правильной организации позволяют с легкостью сменить используемую БД. Они как раз таки и позволяют прогонять запросы через интерфейс и не задумываться об особенностях БД, чтобы защититься от инъекций или просто отправить запрос и получить данные.
Хорошая реализация обертки либо позволяет сложить с себя часть обязанностей по защите данных и их хранению, либо получить объектное представление записей из реляционной БД, к примеру.
Если вы точно не собираетесь менять БД и пишете какую-то служебную утилитку для работы с mysql, часто достаточно mysqli_*-функций.
Если вам нужно объектное отражение записей — вы используете обертку.
Если вам нужна доп. обработка запросов и данных из БД — вы опять используете обертку.
Но если вам нужно получить элемент массива $_SERVER, я не понимаю, зачем здесь нужна обертка.
Чтобы использовать header() мне не нужен «фреймворк». Чтобы обратиться к $_COOKIE мне тоже не нужен набор классов и объектов. Другое дело, если помимо непосредственно обращения к переменной или записи значения в массив мне требуется выполнить еще с десяток операций — тогда я уже задумаюсь.
Но предложенный выше «фреймворк» ничего подобного не предоставляет. И судя по тому, что у ребят на написание синонимов 2 месяца ушло, вряд ли в ближайшие годы я смогу считать его чем-то нужным и стоящим.
В случае тернарного оператора мы точно так же лишь указываем, что переменная является опциональной. С точки зрения читабельности кода, мне ближе именно вариант с тернарным оператором, чем функция, коих в окружении множество.
Но, посмотрев тот самый исходник, на который вы дали ссылку, я так и не понял, чем разработчиков не устроил стандартный php'шный header().
> А если всё равно он используется, то почему бы не воспользоваться его возможностями
А зачем он используется, если не предоставляет ничего нового и дополнительного, а все его возможности изначально заложены в ядро PHP (часто, с более коротким и понятным синтаксисом, более того, известным каждому разработчику, а не только имеющими опыт работы с данным фреймворком). Чтобы воспользоваться теми самыми «уникальными» возможностями, которые и без того имеются?
И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).