PHP
Comments 74
+1
Мне тоже очень понравилось. Простой, удобный, всё кеширует сам, без напоминаний. Смущает только предпоследний абзац — для коммерческого использования нужно «поговорить с разработчиками». Впрочем, для себя любимого можно использовать GPL.
+3
silex тоже простой. Насчет легкости не знаю, не профилировал еще.
+1
Поддерживаю silex. Неоднократно использовал — очень гибкий, расширяемый, но в тоже время простой микро-фреймворк
+2
Ужас, с таким обилием фреймворком на php, нужно писать разработчикам? Нет, спасибо.
0
Не нашел Русской поддержки, надо будет с авторами связаться, и возможно можно будет создать сообщество на Русском.
+1
Когда-то пробовал работать с ними. Очень испугала скорость, а точнее её отсутствие. Хотя, может, я то-то не так делал…
+3
Так же столкнулся с проблемой скорости. Возможно конечно нужно оптимизировать как-то, но знаете тот же PHP из коробки не такой уж медленный…
+3
Самая простая оптимизация — продакшен запускать в режиме production, а не development.
-8
Кто-нить из минусовавших может объяснить минус?
На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?
+23
Кому какая разница как это пишется на рельсах? Блог о PHP и статья о php-фреймворке, зачем лишний раз разводить холивар?
+18
На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?

А на WordPress блог делается за 30 секунд. Вывод — WordPress хуже RoR?
-5
Ну вот твиттер, например, изначально на рельсах был и ничего, вполне себе шустро
+7
Я ж не спорю. Ещё GitHub шустрый на рельсах. Наверное, покрутить какой-нибудь регулятор тормознутости надо.

А вообще вы странные люди — зайти в блог PHP и писать какой хороший Ruby On Rails :-)
+2
А разве это что-то меняет? На Хабре есть блог, посвящённый рельсам. Идите ещё там напишите какой PHP хороший, ласковый и милый.
+1
Ничего там шустрого не было. Fail Whale на каждое меди-событие. Правда, там смешались в кучи кони, люди и RoR виноват и сами разработчики
+5
Вопрос к уважаемым читателям: вам было интереснее в этом посте прочитать «А как у них сделано», «А что за подход» и «А как там интересно роутеры делаются» или всё таки «Угу, хорошая система, буду использовать»?
+4
Хмм… Я уж было удивился, но… 55 килобайт — без шаблонизатора и ORM, только ядро.
+5
Приходилось сталкиваться с этим чудо фреймворком, показалось недостаточно функционала.
Оттолкнули мелки порблемы, как отсутсвие экранирования имен полей в «ORM» (на самом деле data mapper а не полноценная реляционная проекция), отсутствие внятных механизмов фильтрации входящих данных, плюшек упрощающих работу Autoloader и т.п Одним словом прост и быстр, но писать на нем что-то более серьезное, чем свою домашнюю страничку не стал бы.
0
Они ни на что не претендуют со своим ORM, просто несколько ускоряют работу для простых таблиц и view. И честно предупреждают, что join не делают. А если вам это надо — можете легко подключить вашу любимую ORM.
+4
Присоединюсь к первому комментарию по ссылке — это очень хороший Hello, World! для любого фреймворка.
+5
По сабжу:

$id = F3::get('PARAMS[«id»]');
// создаём объект Axon и ищем в нём наш id
$article=new Axon('article');
$article->load(«id='$id'»);

Приведение к типу int делается автоматом?
SQL-инъекции случаем не будет? Используется prepared statements или что?

Шаблоны со smarty-подобным синтаксисом… хм… это как-то не очень хорошо. php сам по себе отличный шаблонизатор, зачем мутить что-то ещё?
+2
Пхп отличный шаблонизатор, поэтому в слое вью на нем так и хочется забабахать какую-нибудь логику из контроллера. Это причина, по которой лично я начал использовать шаблонизаторы.
0
Когда я начал использовать шаблонизатор, логика, относящаяся к view, стала образовываться в контроллерах, а шаблоны — плодиться в огромных количествах. В результате решил использовать PHP в качестве шаблонизатора. Опомнился я совсем недавно, и вот — сейчас продолжаю все переделывать.
+1
Чтоб не вызывать постоянно htmlspecialchars? Чтобы без заморочек использовать наследование шаблонов? Чтобы исключить возможность обращения к всем объектам, методам и переменным, кроме явно заданных?
UFO landed and left these words here
+1
Ну, написали бы почему. Да, можно решить, и даже, наверное изолировать данные представления от всего остального приложения можно (что-то было на хабре на эту тему), но других причин я не вижу. Не считать же всерьез, что синтаксис Smarty или Twig для верстальщика качественно проще синтаксиса самого PHP? А вот чтобы очень умный верстальщик не начал базу в шаблоне дергать — по-моему, очень веская причина использования шаблонизаторов, не дающих коду в шаблоне доступ к глобальному контексту. «Из коробки» такой функциональности в PHP сейчас точно нет и, вроде, в 5.4 не предвидится.
0
Вообще да было бы приятно какой-нибудь способ избавления от переменных и контекста придумать.
+1
И меня тоже это интересует.
Какова скорость работы конструкции $id = F3::get('PARAMS[«id»]');, видимо это хэш?
Как уже сказали, вы приводите пример, и в тоже время всем на обозрение выставляете SQL-инъекцию.
+1
Лёгкость это, конечно, хорошо, но зачем же столько статических методов-то?
+1
А чтоб легкость обеспечить :) Передавать экземпляр F3 во все места, где он может понадобится легкости не добавит, делать глобальной переменной его или синглтоном тоже читаемость и объём кода не уменьшит. В принципе и недостатков в данном случае особых нет у статических методов. И инстанцирование никаких плюсов не даст, т. к. заменять или расширять класс F3 вряд ли понадобится.
0
Вопрос зачем столько регулярок и зачем всё сунуть в одну статическию переменную эмулирующую GLOBALS. Реальное приложение просто падает в корку под нагрузкой.
Да и в целом, подход на сантиметр длиннее голого php, а местами даже короче.
+1
Честно говоря, удивила первая же строка:

require __DIR__.'/lib/base.php';


Не проще ли было написать вот так:

require './lib/base.php';
0
Не ожидаете же, надеюсь, что текущим каталогом в начале исполнения будет не каталог скрипта?
0
Впрочем, я понимаю, что это перевод и он должен быть точен. Но не понимаю, что имел в виду автор первоисточника.
+1
Помниться мне, абсолютные пути лучше чем относительные… чем — не могу сказать, были какие-то аправдания что быстрее подключаются файлы, но я просто превык. Все в моем отделе так пишут… а я чем хуже? Да и проблем особо пока не встречал.
0
Не ожидаете же, надеюсь, что текущим каталогом в начале исполнения будет не каталог скрипта

Мне кажется, дело в том, что тяжело быть уверенным в корректности include path. Возможно, проблема аналогична той, что нельзя использовать $_SERVER['DOCUMENT_ROOT'], так как на разных конфигурациях в нём может быть некорректное значение.

Я всегда стараюсь сделать в инициализонном файле что-то типа:
define( 'ROOT', __DIR__ );

А потом уже использовать константу ROOT для подключения файлов.
0
Мне кажется, дело в том, что тяжело быть уверенным в корректности include path.
Позвольте тотчас же без обиняков сообщить Вам, что официальное пособие чёрным по белому гласит: include_path вовсе не используется, когда задан абсолютный (от «/» в Unix, от «\» в Windows), или относительный (от «./» или от «../») путь к подключаемому файлу.

(И так как в моём примере «./lib/base.php», то include_path не при делах.)
+1
Странная ссылка. Описан костыль, но вот причина его появления упомянута вскользь. Может дело в неправильной конфигурации «our new linux server»? Помню сталкивался с похожим когда только начинал использовать nginx.
+1
Ага. Вполне возможно, что неправильно сконфигурирован пых или ось. Тем не менее, в общим примерах желательно воздержаться от DOCUMENT_ROOT, ведь у пользователя тоже может быть неправильно сконфигурировано что-то, тем более он не так уж и нужен.
0
Относительные пути и так разворачиваются в абсолютные. Этого, как минимум, требует логика работы require_once/include_once. Желание помочь интерпретатору и не делать лишний системный вызов?
+1
Зашел в документации в раздел «Forms Handler», а там такой шаблон:

{{@message}}

Как-то некрасиво совсем…
0
Дабы парсер Хабрахабра не кушал Ваш код, используйте пару тегов <source></source> для обрамления блоков исходного кода, и тем невозбранно достигнете желаемого.
-1
Кушались символы «больше» и «меньше». Оказывается, их тут надо писать html-кодом &gt; и &lt;
Результат: > и < :)
0
Ну, по-моему шаблонизатор должен облегчать жизнь, а не усложнять. В шаблонизаторе F3 даже по сравнению с нативным php синтаксис запутаннее…
Сравните:
<F3:check if="{{!is_null(@message)}}">
{{@message}}
</F3:check>
и
<?php if (!empty($message)):?>
<?=$message?>
<?php endif?>
0
Я как-то привык на синтаксис внимания не обращать :) А тут, похоже, ноги от XSLT растут или схожих идей.
0
Там во многих примерах используется Symfony — т.е. к «микрофреймворку» нужно таскать огромную библиотеку вспомогательных функций? :)
0
Используются компоненты Symfony2, специально заточенные под использование без ядра Symfony2 (часть из них я постепенно ввожу в старые проекты, чтобы не изобретать заменить свои велосипеды). Весь фреймворк (вместе с компонентами) — один файл меньше полмегабайта — таскать можно на дискете :) Правда ORM «из коробки» нет, только DBAL.
0
Буквально пару недель назад начал в очередной раз просматривать фреймворки, требования простые живой, нормальное комьюнити + документация, несколько полезных функций «из коробки» (кеширование, роутинг, работа с БД и т.п.). Среди них был и F3. Покрутил разные, «то то не то»-«то там не так», и все-таки пришел к Yii Framework. Достаточно быстрый и очень широкое применение + еще и обрадовало сообщение от 1 января на Habrahabre — обновился до 1.1.9. И да, это был первый фремйворк, где захотелось участвовать в opensource.
+1
Yii это все таки другой класс. Нет смысл сравнивать микрофреймворк F3, с полноценным фреймворком Yii.
0
Абсолютно поддерживаю.
От себя добавлю, что кроме микро (F3) и миди (CI, Yii, Cake) есть ещё макси (ZF2, Symphony), которые тоже с Codeigniter не очень то и сравниваются.
0
Symfony2 меньше трех метров, Yii 5+ — кто из них миди, а кто макси? :)
0
Имел дело с первой веткой.
Полное гавно, есть пару интересных моментов, но в целом он ужасен, особенно количеством регулярок внутри. Писать на нём реальный проект глупость. Вот начинал писать обзор amdy.su/developing-by-fatfree/, ещё в планах выложить пару исходников, с заказчиком уже договорился, но руки не доходят до второй части.
0
Полез смотреть код, когда увидел, что шаблон url в route передается в виде строки. Поплакал)
/**
		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?
Наверно это микродзен для ускорения производительности?)
0
Автор, а где вы нашли про письмо разработчкиам в случае коммерческого использования?

fatfree.sourceforge.net/page/support-licensing

Я так понял, что для коммерческого использования возможно не использовать GNU GPL v3 и закрывать код. Может я что-то неверно понял?
+1
Автор, а где вы...

Я не автор. Я — переводчик.
Абзац про лицензию также был в оригинальном тексте и я перевёл его. Возможно, что разработчики передумали и открыли код для всех под GPL.
На всякий случай просто уберу этот кусок из топика.
0
Похоже Fat Free сильно обновился, например упоминаний об Axon в свежей версии я не нашел. Вот бы кто-нибудь обновил и мануал…
Only those users with full accounts are able to leave comments., please.