Комментарии 74
Надо будет «пощупать», радует такая легкость.
Не нашел Русской поддержки, надо будет с авторами связаться, и возможно можно будет создать сообщество на Русском.
Как хорошо же писать на рельсах…
Когда-то пробовал работать с ними. Очень испугала скорость, а точнее её отсутствие. Хотя, может, я то-то не так делал…
Кто-нить из минусовавших может объяснить минус?
На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?
На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?
Подобное да, а шаг вправо-шаг влево уже критичнее.
Кому какая разница как это пишется на рельсах? Блог о PHP и статья о php-фреймворке, зачем лишний раз разводить холивар?
На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?
А на WordPress блог делается за 30 секунд. Вывод — WordPress хуже RoR?
Ну вот твиттер, например, изначально на рельсах был и ничего, вполне себе шустро
Я ж не спорю. Ещё GitHub шустрый на рельсах. Наверное, покрутить какой-нибудь регулятор тормознутости надо.
А вообще вы странные люди — зайти в блог PHP и писать какой хороший Ruby On Rails :-)
А вообще вы странные люди — зайти в блог PHP и писать какой хороший Ruby On Rails :-)
Так я еще и на PHP могу)
А разве это что-то меняет? На Хабре есть блог, посвящённый рельсам. Идите ещё там напишите какой PHP хороший, ласковый и милый.
Интересно, PHP = Руби На Рельсах =))
Ничего там шустрого не было. Fail Whale на каждое меди-событие. Правда, там смешались в кучи кони, люди и RoR виноват и сами разработчики
Вопрос к уважаемым читателям: вам было интереснее в этом посте прочитать «А как у них сделано», «А что за подход» и «А как там интересно роутеры делаются» или всё таки «Угу, хорошая система, буду использовать»?
Хмм… Я уж было удивился, но… 55 килобайт — без шаблонизатора и ORM, только ядро.
Приходилось сталкиваться с этим чудо фреймворком, показалось недостаточно функционала.
Оттолкнули мелки порблемы, как отсутсвие экранирования имен полей в «ORM» (на самом деле data mapper а не полноценная реляционная проекция), отсутствие внятных механизмов фильтрации входящих данных, плюшек упрощающих работу Autoloader и т.п Одним словом прост и быстр, но писать на нем что-то более серьезное, чем свою домашнюю страничку не стал бы.
Оттолкнули мелки порблемы, как отсутсвие экранирования имен полей в «ORM» (на самом деле data mapper а не полноценная реляционная проекция), отсутствие внятных механизмов фильтрации входящих данных, плюшек упрощающих работу Autoloader и т.п Одним словом прост и быстр, но писать на нем что-то более серьезное, чем свою домашнюю страничку не стал бы.
От ORM там только название.
«Пишем свой блог с фреймворком»
Может не совсем в тему, но напомнило мне один тред со stackoverflow: Why does every man and his dog want to code a blogging engine?
По сабжу:
Приведение к типу int делается автоматом?
SQL-инъекции случаем не будет? Используется prepared statements или что?
Шаблоны со smarty-подобным синтаксисом… хм… это как-то не очень хорошо. php сам по себе отличный шаблонизатор, зачем мутить что-то ещё?
$id = F3::get('PARAMS[«id»]');
// создаём объект Axon и ищем в нём наш id
$article=new Axon('article');
$article->load(«id='$id'»);
Приведение к типу int делается автоматом?
SQL-инъекции случаем не будет? Используется prepared statements или что?
Шаблоны со smarty-подобным синтаксисом… хм… это как-то не очень хорошо. php сам по себе отличный шаблонизатор, зачем мутить что-то ещё?
Пхп отличный шаблонизатор, поэтому в слое вью на нем так и хочется забабахать какую-нибудь логику из контроллера. Это причина, по которой лично я начал использовать шаблонизаторы.
Чтоб не вызывать постоянно htmlspecialchars? Чтобы без заморочек использовать наследование шаблонов? Чтобы исключить возможность обращения к всем объектам, методам и переменным, кроме явно заданных?
НЛО прилетело и опубликовало эту надпись здесь
Ну, написали бы почему. Да, можно решить, и даже, наверное изолировать данные представления от всего остального приложения можно (что-то было на хабре на эту тему), но других причин я не вижу. Не считать же всерьез, что синтаксис Smarty или Twig для верстальщика качественно проще синтаксиса самого PHP? А вот чтобы очень умный верстальщик не начал базу в шаблоне дергать — по-моему, очень веская причина использования шаблонизаторов, не дающих коду в шаблоне доступ к глобальному контексту. «Из коробки» такой функциональности в PHP сейчас точно нет и, вроде, в 5.4 не предвидится.
И меня тоже это интересует.
Какова скорость работы конструкции
Как уже сказали, вы приводите пример, и в тоже время всем на обозрение выставляете SQL-инъекцию.
Какова скорость работы конструкции
$id = F3::get('PARAMS[«id»]');, видимо это хэш?Как уже сказали, вы приводите пример, и в тоже время всем на обозрение выставляете SQL-инъекцию.
Прямо bottlepy для PHP
Лёгкость это, конечно, хорошо, но зачем же столько статических методов-то?
А чтоб легкость обеспечить :) Передавать экземпляр F3 во все места, где он может понадобится легкости не добавит, делать глобальной переменной его или синглтоном тоже читаемость и объём кода не уменьшит. В принципе и недостатков в данном случае особых нет у статических методов. И инстанцирование никаких плюсов не даст, т. к. заменять или расширять класс F3 вряд ли понадобится.
Вопрос зачем столько регулярок и зачем всё сунуть в одну статическию переменную эмулирующую GLOBALS. Реальное приложение просто падает в корку под нагрузкой.
Да и в целом, подход на сантиметр длиннее голого php, а местами даже короче.
Да и в целом, подход на сантиметр длиннее голого php, а местами даже короче.
Честно говоря, удивила первая же строка:
Не проще ли было написать вот так:
require __DIR__.'/lib/base.php';
Не проще ли было написать вот так:
require './lib/base.php';
Не ожидаете же, надеюсь, что текущим каталогом в начале исполнения будет не каталог скрипта?
Впрочем, я понимаю, что это перевод и он должен быть точен. Но не понимаю, что имел в виду автор первоисточника.
Не ожидаете же, надеюсь, что текущим каталогом в начале исполнения будет не каталог скрипта
Мне кажется, дело в том, что тяжело быть уверенным в корректности include path. Возможно, проблема аналогична той, что нельзя использовать
$_SERVER['DOCUMENT_ROOT'], так как на разных конфигурациях в нём может быть некорректное значение.Я всегда стараюсь сделать в инициализонном файле что-то типа:
define( 'ROOT', __DIR__ );
А потом уже использовать константу ROOT для подключения файлов.
Мне кажется, дело в том, что тяжело быть уверенным в корректности include path.Позвольте тотчас же без обиняков сообщить Вам, что официальное пособие чёрным по белому гласит: include_path вовсе не используется, когда задан абсолютный
(И так как в моём примере «./lib/base.php», то include_path не при делах.)
Странная ссылка. Описан костыль, но вот причина его появления упомянута вскользь. Может дело в неправильной конфигурации «our new linux server»? Помню сталкивался с похожим когда только начинал использовать nginx.
Относительные пути и так разворачиваются в абсолютные. Этого, как минимум, требует логика работы require_once/include_once. Желание помочь интерпретатору и не делать лишний системный вызов?
Зашел в документации в раздел «Forms Handler», а там такой шаблон:
{{@message}}
Как-то некрасиво совсем…
{{@message}}
Как-то некрасиво совсем…
хабр скушал код:)
короче, пример некрасивого шаблона с самого верху на fatfree.sourceforge.net/page/forms-handler
короче, пример некрасивого шаблона с самого верху на fatfree.sourceforge.net/page/forms-handler
Дабы парсер Хабрахабра не кушал Ваш код, используйте пару тегов <source>…</source> для обрамления блоков исходного кода, и тем невозбранно достигнете желаемого.
А что не нравится?
Мне, из микро-фреймворков на PHP, больше всего радует Silex.
habrahabr.ru/blogs/symfony/118011/ — обзор на хабре для заинтересовавшихся.
Там во многих примерах используется Symfony — т.е. к «микрофреймворку» нужно таскать огромную библиотеку вспомогательных функций? :)
Используются компоненты Symfony2, специально заточенные под использование без ядра Symfony2 (часть из них я постепенно ввожу в старые проекты, чтобы не изобретать заменить свои велосипеды). Весь фреймворк (вместе с компонентами) — один файл меньше полмегабайта — таскать можно на дискете :) Правда ORM «из коробки» нет, только DBAL.
Буквально пару недель назад начал в очередной раз просматривать фреймворки, требования простые живой, нормальное комьюнити + документация, несколько полезных функций «из коробки» (кеширование, роутинг, работа с БД и т.п.). Среди них был и F3. Покрутил разные, «то то не то»-«то там не так», и все-таки пришел к Yii Framework. Достаточно быстрый и очень широкое применение + еще и обрадовало сообщение от 1 января на Habrahabre — обновился до 1.1.9. И да, это был первый фремйворк, где захотелось участвовать в opensource.
Имел дело с первой веткой.
Полное гавно, есть пару интересных моментов, но в целом он ужасен, особенно количеством регулярок внутри. Писать на нём реальный проект глупость. Вот начинал писать обзор amdy.su/developing-by-fatfree/, ещё в планах выложить пару исходников, с заказчиком уже договорился, но руки не доходят до второй части.
Полное гавно, есть пару интересных моментов, но в целом он ужасен, особенно количеством регулярок внутри. Писать на нём реальный проект глупость. Вот начинал писать обзор amdy.su/developing-by-fatfree/, ещё в планах выложить пару исходников, с заказчиком уже договорился, но руки не доходят до второй части.
Полез смотреть код, когда увидел, что шаблон url в route передается в виде строки. Поплакал)
Строка с разбивкой $pattern по пробельным символам и лимитом 2. Интересно, то есть они заведомо предполагают, что там будет передан метод и ссылка, так почему же не сделать было метод класса с параметрами $method, $pattern вместо $method.' '.$pattern?
Наверно это микродзен для ускорения производительности?)
/**
Assign handler to route pattern
@param $pattern string
@param $funcs mixed
@param $ttl int
@param $throttle int
@param $hotlink bool
@public
**/
static function route($pattern,$funcs,$ttl=0,$throttle=0,$hotlink=TRUE) {
list($methods,$uri)=
preg_split('/\s+/',$pattern,2,PREG_SPLIT_NO_EMPTY);
foreach (self::split($methods) as $method)
// Use pattern and HTTP methods as route indexes
self::$vars['ROUTES'][$uri][strtoupper($method)]=
// Save handler, cache timeout and hotlink permission
array($funcs,$ttl,$throttle,$hotlink);
}
Строка с разбивкой $pattern по пробельным символам и лимитом 2. Интересно, то есть они заведомо предполагают, что там будет передан метод и ссылка, так почему же не сделать было метод класса с параметрами $method, $pattern вместо $method.' '.$pattern?
Наверно это микродзен для ускорения производительности?)
Автор, а где вы нашли про письмо разработчкиам в случае коммерческого использования?
fatfree.sourceforge.net/page/support-licensing
Я так понял, что для коммерческого использования возможно не использовать GNU GPL v3 и закрывать код. Может я что-то неверно понял?
fatfree.sourceforge.net/page/support-licensing
Я так понял, что для коммерческого использования возможно не использовать GNU GPL v3 и закрывать код. Может я что-то неверно понял?
Похоже Fat Free сильно обновился, например упоминаний об Axon в свежей версии я не нашел. Вот бы кто-нибудь обновил и мануал…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем свой блог с фреймворком Fat-Free Framework