@kafeman2 янв 2012 в 17:48

Пишем свой блог с фреймворком Fat-Free Framework

8 мин

24K

PHP *

Туториал

Перевод

+30

Комментарии 74

@AlexanderPHP 2 янв 2012 в 18:01

Надо будет «пощупать», радует такая легкость.

@kafeman 2 янв 2012 в 18:03

Мне тоже очень понравилось. Простой, удобный, всё кеширует сам, без напоминаний. Смущает только предпоследний абзац — для коммерческого использования нужно «поговорить с разработчиками». Впрочем, для себя любимого можно использовать GPL.

@Fedcomp 2 янв 2012 в 19:46

silex тоже простой. Насчет легкости не знаю, не профилировал еще.

@Zona 2 янв 2012 в 19:55

Поддерживаю silex. Неоднократно использовал — очень гибкий, расширяемый, но в тоже время простой микро-фреймворк

@Magiq 2 янв 2012 в 21:02

Ужас, с таким обилием фреймворком на php, нужно писать разработчикам? Нет, спасибо.

@AlexanderPHP 2 янв 2012 в 18:31

Не нашел Русской поддержки, надо будет с авторами связаться, и возможно можно будет создать сообщество на Русском.

@kafeman 2 янв 2012 в 18:32

Хорошая идея. Блог для сообщества уже есть.

@KriMs 2 янв 2012 в 18:53

Как хорошо же писать на рельсах…

@kafeman 2 янв 2012 в 18:59

Когда-то пробовал работать с ними. Очень испугала скорость, а точнее её отсутствие. Хотя, может, я то-то не так делал…

@vit1251 3 янв 2012 в 04:14

Так же столкнулся с проблемой скорости. Возможно конечно нужно оптимизировать как-то, но знаете тот же PHP из коробки не такой уж медленный…

@Aux 3 янв 2012 в 11:13

Самая простая оптимизация — продакшен запускать в режиме production, а не development.

@KriMs 2 янв 2012 в 19:32

Кто-нить из минусовавших может объяснить минус?
На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?

@Nc_Soft 2 янв 2012 в 19:51

Подобное да, а шаг вправо-шаг влево уже критичнее.

@Davert 2 янв 2012 в 20:59

Рельсы менее расширяемы чем F3? Да вы что?

@Powerslave 2 янв 2012 в 20:54

Кому какая разница как это пишется на рельсах? Блог о PHP и статья о php-фреймворке, зачем лишний раз разводить холивар?

@TheShock 2 янв 2012 в 21:29

На рельсах подобное за 5 минут пишется. Смысл столько с этим возиться?

А на WordPress блог делается за 30 секунд. Вывод — WordPress хуже RoR?

@TheShock 3 янв 2012 в 05:44

Спеллфикс: «Вывод — WordPress лучше RoR?»

@AloneCoder 2 янв 2012 в 19:09

Ну вот твиттер, например, изначально на рельсах был и ничего, вполне себе шустро

@kafeman 2 янв 2012 в 19:14

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

А вообще вы странные люди — зайти в блог PHP и писать какой хороший Ruby On Rails :-)

@AloneCoder 2 янв 2012 в 19:17

Так я еще и на PHP могу)

@kafeman 2 янв 2012 в 19:21

А разве это что-то меняет? На Хабре есть блог, посвящённый рельсам. Идите ещё там напишите какой PHP хороший, ласковый и милый.

@TheShock 2 янв 2012 в 21:30

Интересно, PHP = Руби На Рельсах =))

@dmitriid 3 янв 2012 в 08:12

Ничего там шустрого не было. Fail Whale на каждое меди-событие. Правда, там ~~смешались в кучи кони, люди~~ и RoR виноват и сами разработчики

@ainu 2 янв 2012 в 20:52

Вопрос к уважаемым читателям: вам было интереснее в этом посте прочитать «А как у них сделано», «А что за подход» и «А как там интересно роутеры делаются» или всё таки «Угу, хорошая система, буду использовать»?

@ainu 2 янв 2012 в 20:58

Хмм… Я уж было удивился, но… 55 килобайт — без шаблонизатора и ORM, только ядро.

@coh 2 янв 2012 в 21:43

Приходилось сталкиваться с этим чудо фреймворком, показалось недостаточно функционала.
Оттолкнули мелки порблемы, как отсутсвие экранирования имен полей в «ORM» (на самом деле data mapper а не полноценная реляционная проекция), отсутствие внятных механизмов фильтрации входящих данных, плюшек упрощающих работу Autoloader и т.п Одним словом прост и быстр, но писать на нем что-то более серьезное, чем свою домашнюю страничку не стал бы.

@Elfet 2 янв 2012 в 21:48

От ORM там только название.

@victorburre 17 янв 2012 в 23:21

Они ни на что не претендуют со своим ORM, просто несколько ускоряют работу для простых таблиц и view. И честно предупреждают, что join не делают. А если вам это надо — можете легко подключить вашу любимую ORM.

@StraNNikk 2 янв 2012 в 22:18

«Пишем свой блог с фреймворком»

Может не совсем в тему, но напомнило мне один тред со stackoverflow: Why does every man and his dog want to code a blogging engine?

@ainu 3 янв 2012 в 03:22

Присоединюсь к первому комментарию по ссылке — это очень хороший Hello, World! для любого фреймворка.

@StraNNikk 3 янв 2012 в 09:10

«Writing a blog engine is the new Hello World» воистину! :)

@StraNNikk 2 янв 2012 в 22:32

По сабжу:

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

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

Шаблоны со smarty-подобным синтаксисом… хм… это как-то не очень хорошо. php сам по себе отличный шаблонизатор, зачем мутить что-то ещё?

@quantum 2 янв 2012 в 23:23

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

@powder96 3 янв 2012 в 02:59

Когда я начал использовать шаблонизатор, логика, относящаяся к view, стала образовываться в контроллерах, а шаблоны — плодиться в огромных количествах. В результате решил использовать PHP в качестве шаблонизатора. Опомнился я совсем недавно, и вот — сейчас продолжаю все переделывать.

@VolCh 3 янв 2012 в 00:16

Чтоб не вызывать постоянно htmlspecialchars? Чтобы без заморочек использовать наследование шаблонов? Чтобы исключить возможность обращения к всем объектам, методам и переменным, кроме явно заданных?

НЛО прилетело и опубликовало эту надпись здесь

@VolCh 3 янв 2012 в 02:35

Ну, написали бы почему. Да, можно решить, и даже, наверное изолировать данные представления от всего остального приложения можно (что-то было на хабре на эту тему), но других причин я не вижу. Не считать же всерьез, что синтаксис Smarty или Twig для верстальщика качественно проще синтаксиса самого PHP? А вот чтобы очень умный верстальщик не начал базу в шаблоне дергать — по-моему, очень веская причина использования шаблонизаторов, не дающих коду в шаблоне доступ к глобальному контексту. «Из коробки» такой функциональности в PHP сейчас точно нет и, вроде, в 5.4 не предвидится.

@vit1251 3 янв 2012 в 04:22

Вообще да было бы приятно какой-нибудь способ избавления от переменных и контекста придумать.

@Demetros 3 янв 2012 в 07:36

И меня тоже это интересует.
Какова скорость работы конструкции $id = F3::get('PARAMS[«id»]');, видимо это хэш?
Как уже сказали, вы приводите пример, и в тоже время всем на обозрение выставляете SQL-инъекцию.

@bndr 3 янв 2012 в 04:39

Прямо bottlepy для PHP

@zerkms 3 янв 2012 в 04:44

Лёгкость это, конечно, хорошо, но зачем же столько статических методов-то?

@VolCh 3 янв 2012 в 05:35

А чтоб легкость обеспечить :) Передавать экземпляр F3 во все места, где он может понадобится легкости не добавит, делать глобальной переменной его или синглтоном тоже читаемость и объём кода не уменьшит. В принципе и недостатков в данном случае особых нет у статических методов. И инстанцирование никаких плюсов не даст, т. к. заменять или расширять класс F3 вряд ли понадобится.

@AmdY 3 янв 2012 в 21:07

Вопрос зачем столько регулярок и зачем всё сунуть в одну статическию переменную эмулирующую GLOBALS. Реальное приложение просто падает в корку под нагрузкой.
Да и в целом, подход на сантиметр длиннее голого php, а местами даже короче.

@Mithgol 3 янв 2012 в 06:50

Честно говоря, удивила первая же строка:

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

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

require './lib/base.php';

@Mithgol 3 янв 2012 в 06:53

Не ожидаете же, надеюсь, что текущим каталогом в начале исполнения будет не каталог скрипта?

@Mithgol 3 янв 2012 в 06:54

Впрочем, я понимаю, что это перевод и он должен быть точен. Но не понимаю, что имел в виду автор первоисточника.

@Fesor 3 янв 2012 в 07:35

Помниться мне, абсолютные пути лучше чем относительные… чем — не могу сказать, были какие-то аправдания что быстрее подключаются файлы, но я просто превык. Все в моем отделе так пишут… а я чем хуже? Да и проблем особо пока не встречал.

@Fesor 3 янв 2012 в 07:35

Черт. Опять опечатки… Ну вот как проснуться?

@TheShock 3 янв 2012 в 07:42

Не ожидаете же, надеюсь, что текущим каталогом в начале исполнения будет не каталог скрипта

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

Я всегда стараюсь сделать в инициализонном файле что-то типа:

define( 'ROOT', __DIR__ );

А потом уже использовать константу ROOT для подключения файлов.

@Mithgol 3 янв 2012 в 10:49

Мне кажется, дело в том, что тяжело быть уверенным в корректности include path.

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

(И так как в моём примере «./lib/base.php», то include_path не при делах.)

@VolCh 3 янв 2012 в 12:22

Странная ссылка. Описан костыль, но вот причина его появления упомянута вскользь. Может дело в неправильной конфигурации «our new linux server»? Помню сталкивался с похожим когда только начинал использовать nginx.

@TheShock 3 янв 2012 в 12:24

Ага. Вполне возможно, что неправильно сконфигурирован пых или ось. Тем не менее, в общим примерах желательно воздержаться от DOCUMENT_ROOT, ведь у пользователя тоже может быть неправильно сконфигурировано что-то, тем более он не так уж и нужен.

@VolCh 3 янв 2012 в 12:19

Относительные пути и так разворачиваются в абсолютные. Этого, как минимум, требует логика работы require_once/include_once. Желание помочь интерпретатору и не делать лишний системный вызов?

@korvin0 3 янв 2012 в 08:28

Зашел в документации в раздел «Forms Handler», а там такой шаблон:

{{@message}}

Как-то некрасиво совсем…

@korvin0 3 янв 2012 в 08:34

хабр скушал код:)
короче, пример некрасивого шаблона с самого верху на fatfree.sourceforge.net/page/forms-handler

@Mithgol 3 янв 2012 в 10:52

Дабы парсер Хабрахабра не кушал Ваш код, используйте пару тегов <source>…</source> для обрамления блоков исходного кода, и тем невозбранно достигнете желаемого.

@korvin0 3 янв 2012 в 13:24

Кушались символы «больше» и «меньше». Оказывается, их тут надо писать html-кодом > и <
Результат: > и < :)

@VolCh 3 янв 2012 в 12:35

А что не нравится?

@korvin0 3 янв 2012 в 13:16

Ну, по-моему шаблонизатор должен облегчать жизнь, а не усложнять. В шаблонизаторе F3 даже по сравнению с нативным php синтаксис запутаннее…
Сравните:
<F3:check if="{{!is_null(@message)}}">
{{@message}}
</F3:check>
и
<?php if (!empty($message)):?>
<?=$message?>
<?php endif?>

@VolCh 3 янв 2012 в 13:37

Я как-то привык на синтаксис внимания не обращать :) А тут, похоже, ноги от XSLT растут или схожих идей.

@KeepYourMind 3 янв 2012 в 08:50

Мне, из микро-фреймворков на PHP, больше всего радует Silex.

@VolCh 3 янв 2012 в 12:39

habrahabr.ru/blogs/symfony/118011/ — обзор на хабре для заинтересовавшихся.

@shifty 3 янв 2012 в 15:37

slimframework.com

@diamant 3 янв 2012 в 16:17

Там во многих примерах используется Symfony — т.е. к «микрофреймворку» нужно таскать огромную библиотеку вспомогательных функций? :)

@VolCh 3 янв 2012 в 21:21

Используются компоненты Symfony2, специально заточенные под использование без ядра Symfony2 (часть из них я постепенно ввожу в старые проекты, чтобы ~~не изобретать~~ заменить свои велосипеды). Весь фреймворк (вместе с компонентами) — один файл меньше полмегабайта — таскать можно на дискете :) Правда ORM «из коробки» нет, только DBAL.

@Vertex 3 янв 2012 в 13:38

Буквально пару недель назад начал в очередной раз просматривать фреймворки, требования простые живой, нормальное комьюнити + документация, несколько полезных функций «из коробки» (кеширование, роутинг, работа с БД и т.п.). Среди них был и F3. Покрутил разные, «то то не то»-«то там не так», и все-таки пришел к Yii Framework. Достаточно быстрый и очень широкое применение + еще и обрадовало сообщение от 1 января на Habrahabre — обновился до 1.1.9. И да, это был первый фремйворк, где захотелось участвовать в opensource.

@fStrange 3 янв 2012 в 15:16

Yii это все таки другой класс. Нет смысл сравнивать микрофреймворк F3, с полноценным фреймворком Yii.

@ainu 3 янв 2012 в 17:36

Абсолютно поддерживаю.
От себя добавлю, что кроме микро (F3) и миди (CI, Yii, Cake) есть ещё макси (ZF2, Symphony), которые тоже с Codeigniter не очень то и сравниваются.

@VolCh 3 янв 2012 в 21:28

Symfony2 меньше трех метров, Yii 5+ — кто из них миди, а кто макси? :)

@AmdY 3 янв 2012 в 21:02

Имел дело с первой веткой.
Полное гавно, есть пару интересных моментов, но в целом он ужасен, особенно количеством регулярок внутри. Писать на нём реальный проект глупость. Вот начинал писать обзор amdy.su/developing-by-fatfree/, ещё в планах выложить пару исходников, с заказчиком уже договорился, но руки не доходят до второй части.

@xmdy 3 янв 2012 в 22:51

Полез смотреть код, когда увидел, что шаблон 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?
Наверно это микродзен для ускорения производительности?)

@ChemAli 4 янв 2012 в 12:04

Автор, а где вы нашли про письмо разработчкиам в случае коммерческого использования?

fatfree.sourceforge.net/page/support-licensing

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

@kafeman 4 янв 2012 в 13:11

Автор, а где вы...

Я не автор. Я — переводчик.
Абзац про лицензию также был в оригинальном тексте и я перевёл его. Возможно, что разработчики передумали и открыли код для всех под GPL.
На всякий случай просто уберу этот кусок из топика.

@xredor 30 июл 2013 в 15:30

Похоже Fat Free сильно обновился, например упоминаний об Axon в свежей версии я не нашел. Вот бы кто-нибудь обновил и мануал…

Зарегистрируйтесь на Хабре, чтобы оставить комментарий