FuelPHP — фреймворк с полным баком

Fuel — это простой, гибкий, управляемый сообществом php5-фреймворк, родившийся благодаря разочарованию в имеющихся инструментах. Таким слоганом нас встречает сайт фреймворка — fuelphp.com.

Разработчики — Dan Horrigan, Phil Sturgeon, Jelmer Schreuder и другие участники сообщества. Ребята являлись (являются?) активными участниками сообщества Codeigniter, но разочаровались в темпах его развития (сейчас разработка Codeigniter ведется более активно, на два фронта — Codeigniter Core и комьюнити-драйвен-версия Codeigniter Reactor). В результате родился Fuel. Что ж, давайте рассмотрим его поближе.

FuelPHP распространяется по лицензии MIT. Активная разработка ведется с октября 2010, выход первой бета-версии планировался на 1.1.11. Но, как обычно и бывает в нашем нелегком программерском деле, срок перенесен на 7.1.11. Несмотря на это, уже сейчас можно познакомиться с исходным кодом, документацией и возможностями фреймворка. А возможности многообещающие.

Требования


  • PHP 5.3 или выше
  • Веб-сервер (протестировано на Apache, IIS, nginx)

Возможности


Реализованные:
  • HMVC
  • Каскадная файловая система (как в Kohana)
  • Pakages — модули для расширения функциональности
  • ActiveRecord
  • Утилита командной строки oil (создание заданий для cron, выполнение миграций, запуск тестов)
  • Интегрированные средства отладки Krumo
  • Классы для работы с cookies, session, email, ftp, upload, security, form, validation, route, cache и др.

Запланированные:
  • Модули аутентификации и ACL
  • Публикация примеров приложений на github

Тест-драйв


Скачиваем последнюю версию с github и распаковываем в wwwroot/fuel. Структура каталогов:
public/ - директория, доступная из web
      assets/
      index.php
docs/
fuel/
      app/
            cache/
            classes/
                  controller/
                        welcome.php
                  model/
            config/
            logs/
            migrations/
            modules/
            tasks/
            tmp/
            views/
                  welcome/
                        404.php
                        index.php
            bootstrap.php
      core/
      pakages/

Заходим на http://localhost/fuel/public/

FuelPHP - Welcome screen

Создадим собственный контроллер по умолчанию — fuel/app/classes/controller/testdrive.php:

<?php
class Controller_Testdrive extends Controller {
    public function action_index()
    {
        $this->render(
            'testdrive/index',
            array(
                'hello' => 'Hello Fuel!',
            )
        );
    }
}

В приведенном примере представлению testdrive/index передана переменная $hello со значением 'Hello Fuel!'.

Укажем в файле конфигурации fuel/app/config/config.php новый контроллер по умолчанию:

'routes' => array(
    // This is the default route.  We use a "#" here so that we do not have any
    // reserved routes.
    '#' => 'testdrive',
    '404' => 'welcome/404',
),
 

Файл представления fuel/app/views/testdrive/index.php:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Fuel PHP Framework Testdrive</title>
</head>
<body>
    <?php echo $hello; ?>
</body>
</html>
 

Обновляем страницу и получаем на выходе наш 'Hello Fuel!'.

Выводы


Fuel заслуживает внимания php-разработчиков, не желающих тратить время на длительное изучение и конфигурирование тяжеловесных фреймворков, но нуждающихся в современных инструментах для разработки веб-приложений. А учитывая всего лишь чуть более чем 2х-месячный возраст, от него стоит ожидать ещё больших достижений.

Ссылки


Сайт фреймворка — http://fuelphp.com
Исходный код — https://github.com/fuel/fuel
Поддержка — http://community.fuelphp.com/fuelphp
How fast is Fuel? — http://dhorrigan.com/blog/article/how-fast-is-fuel
Introducing FuelPHP — http://philsturgeon.co.uk/news/2011/01/introducing-fuelphp
Twitter — http://twitter.com/fuelphp
Примеры приложений на fuelphp — http://scrapyrd.com, http://amiafucktard.com
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 123
  • +7
    В чем его преимущества перед другими фреймворками, например перед Yii?
    • +13
      Или перед «Кохана»
      • +4
        О преимуществах говорить пока рано, потому что фреймворк очень молодой, не было ещё ни одного релиза. Yii тоже не сразу стал таким, каким он является сейчас. Но судя по темпам разработки, иметь его ввиду всё же стоит
        • +1
          Кстати, одна из планируемых «модных» фич — поддержка NoSQL из коробки
          • +15
            Вот как появятся преимущества, так и надо пиариться.
          • +2
            Тогда — зачем он нужен?
            • –6
              Надо оценивать не текущее состояние, а перспективы. Предлагать свои идеи, принимать участие в создании и т.д. Это же community-driven framework, поэтому от нас с вами в том числе зависит его будущее. Хотя, пользоваться всем готовым, конечно, намного проще…
              • +2
                Вы у Путина учились отвечать на прямые вопросы? Давайте попробуем ещё раз. Зачем он (фреймворк, а не Путин) нужен?
                • –3
                  Кому нужен? Вам, мне или дяде Васе? А может его авторам?
                  На этот вопрос каждый отвечает для себя сам
                • +2
                  к топику/фреймворку отношения не имею. Но от снобизма подташнивает ;)

                  «Зачем он (фреймворк) нужен?»
                  Если Вам не нужен — не изучайте. Многим может быть полезен для:
                  — веб-разработки
                  — познания нового
                  — стырить пару удачных запчастей для своего недоделаного велосипеда
                  — увидеть кривые запчасти, понять что свои в своем велике тоже местами не выпрямил.
                  — полюбопытствовать ххх'сти-ххх'цать-ххх'м взглядом на мир

                  возможны и другие варианты, эти даны навскидку.

                  • +2
                    Примерно это я и пытался ответить, а меня обвинили в демагогии. Лично у меня паталогическая тяга ко всему новому, поэтому мне очень интересно наблюдать за развитием разных новых фреймворков/библиотек и т.д., плюс действительно можно почерпнуть много разных интересных идей, изучая исходники.
                    Кому-то другому возможно понравится его скорость, удобство или что-то ещё. Я же не могу сразу за всех ответить
          • +3
            Бегло взглянув на код:

            — Полная поддержка php5.3, в том числе замыкания и неймспейсы (чего крайне хочется в кохане)
            — ActiveRecord
            — Консоль из коробки и миграции
            — Более приятные стандарты кодирования, похожие на Zend

            Вообще, мне эта ситуация очень напоминает момент, когда Kohana форкнулась от Codeigniter потому что в нём не было многих новинок php5. Тут тоже самое, только версия php5.3 + стандарты кодирования более привычные для Zend — Symfony разработчиков
          • +3
            На данном этапе о преимуществах не совсем корректно говорить. Если сравнивать с Yii — нравится тенденция получения из коробки жизненно необходимых для работы модулей (email, ftp, upload). Понимаю, что это не проблема, но все-же
            • 0
              Спасибо. Посмотрим, что будет дальше…
          • +2
            Давно уже присматриваюсь к этому фреймворку. Темпы разработки радуют. Обещанные возможности — тоже. Если так пойдёт и дальше — возможно попробую использовать его в реальных проектах, когда выйдет хотя бы первая стабильная версия.

            Несмотря на то, что у них написано, что FuelPHP не является прямым форком ни одного существующего фреймворка, при первом ознакомлении по структуре каталогов/именовании классов очень сильно напомнил мне Кохану
            • –3
              обещанного три года ждут
              • 0
                90% высказываний обычно берут из личного опыта/желаний/соображений. Не стоит судить по себе других, некоторые любят работать и выполнять обещаное… Это так, просто намек на то что стоит думать перед тем как говорить.
            • +4
              OMFG, это вот так two-step view нужно использовать? ну уж нет

              
              class Controller_Home extends Controller\Base {
                  //create the view
                  $view = new View('layout');
              
                  //assign variables
                  $view->username = 'Joe14';
                  $view->set('title', 'Home');
                  $view->site_title = 'My Website';
              
                  //assign views as variables
                  $view->head = new View('head');
                  $view->header = new View('header');
                  $view->content = new View('content');
                  $view->footer = new View('footer');
              
                  //assign to browser output
                  $this->output = $view;
              }
              
              • –1
                Это, конечно, некрасиво. Но можно ведь и таким образом поступить:

                $view = new View('layout');
                $content = new View('content/index');
                $layout->content = $content->render();
                $this->output = $view;
                • +1
                  $view = new View('layout');
                  $content = new View('content/index');
                  $view->content = $content->render();
                  $this->output = $view;
                  • +6
                    <?php
                    class SiteController extends Controller {
                    
                    	public function actionIndex()
                    	{
                    		// Указывать layout не обязательно, по умолчанию грузится main
                    		$this->layout = 'myNonStandardLayoutFile';
                    		$this->render('template', array('myVar' => 10));
                    	}
                    }
                    

                    Блоки layout'a в Yii по другому подключаются, так что такого в коде, как $this->header, $this->footer просто нету — код гораздо короче и проще. Ну и Widgets очень сильно способствуют разгрузке кода контроллеров.
                    • 0
                      А как по-другому вложить в один блок другой? Либо через контроллер (если есть какая-то динамика), либо внутри самого блока:
                      // вьюшка layout
                      <div id="header">
                         <?php echo View::factory('layout/header') ?>
                      </div>
                      <div id="content">
                         <?php echo View::factory('content/index', array('myVar' => 10)) ?>
                      </div>
                      <div id="footer">
                         <?php echo View::factory('layout/footer') ?>
                      </div>
                      
                      • 0
                        В Yii свой механизм, я его юзаю, но пока детально не разобрался :) Так что пока больше сказать не могу
                        • +1
                          Блин, балует вас там хорошая документация :) В Kohana пока внутренности не изучишь, нормально использовать толком и не получится.
                          • +2
                            Доки по Yii не такие уж хорошие (детальные) как хотелось бы. Все равно частенько приходится самому копать, то что в доках не указано. Очень помогает официальный форум. Кодеры там башковитые тусят — не раз спасали.
                          • 0
                            Дык это через контроллер и получается ))
                            • 0
                              можно и во вьюхе
                              • 0
                                Да тут просто выше заявили, что в Yii «код гораздо короче и проще», вот было интересно, чем он проще. Выглядит примерно так же, возможности те же вроде ))
                                • 0
                                  ну, вообще, в 99% случаев я использую 1 строку в контроллере:
                                  $this->render('index',compact('var'));
                    • +1
                      Погодите, а еще красивее и через статик разве нельзя?

                      Типа:
                      $content = Array('foo' => 'bar');
                      $this->output = View::factory('layout', $content);
                      
                      • +1
                        Согласен, через статик красивее. Но немножко не так. $content — это уже обработанное полноценное представление, включаемое в лайаут.
                        • –2
                          Kohana Des? ^__^
                          • 0
                            а еще красивее в content/index сделать include 'header'…
                            • 0
                              и потом искать незакрытые дивы?
                              • 0
                                если правильно верстать то ничего искать не придеться
                                • 0
                                  А еще в моей любименькой IDE будет подсвечиваться ошибка!
                                  • 0
                                    Может предложите в один файл все писать? Мешать PHP с HTML? Дело человек говорит, а Вы язвите
                                    • 0
                                      Наткнулся тут. На самом деле человек говорит совершенно не дело

                                      <?= $header ?>
                                      
                                      
                                      • 0
                                        Отправилось раньше

                                        Content:
                                        <?= $header ?>
                                        	<!-- Content -->
                                        <?= $footer ?>
                                        


                                        Это плохой подход, потому что хедер и футер будут выглядеть где-то так:

                                        Header:
                                        <html>
                                        	<head>
                                        		<title><?= $title ?></title>
                                        	</head>
                                        	<body>
                                        		<div id="content">
                                        


                                        Footer:
                                        		</div>
                                        	</body>
                                        </html>
                                        


                                        Естественно, IDE будет плеваться на эту хрень. Куда лучше такой вариант
                                        Content:
                                        <!-- Content -->
                                        


                                        Overall:
                                        <html>
                                        	<head>
                                        		<title><?= $title ?></title>
                                        	</head>
                                        	<body>
                                        		<div id="content">
                                        			<?= $content ?>
                                        		</div>
                                        	</body>
                                        </html>
                                        


                                        То есть у нас есть один общий Overall, в который мы инджектим Content, а не два (Хедер+Футер), которые мы инджектим в Content. Ide не сходит с ума, мы видим, что открыто, что закрыто, и при необходимости можем подставлять разные врапперы
                                        • 0
                                          Вы не правы, там подключается один файл основной, как вы сделаете подключение хедера и футера уже Ваши проблемы. Вполне будет работать и как Вы сказалои «правильный» вариант.
                                          • 0
                                            Я не говорю про сабжевый фреймворк, я говорю про два подхода.
                                            В Кохане (с которого и слизан FuelPHP) я именно так и сделал, как описал.
                                            В FuelPHP, уверен, тоже можно.
                                • +1
                                  Не соглашусь. Во-первых, в этом случае теряется вся прелесть каскадности (ну или придётся писать include Fuel::find_file('header')), а во-вторых, области видимости переменных хедера и всего остального объединяются, в результате чего надо будет особо пристально следить за названиями переменных, чтобы случайно что-нибудь не перезаписать. Иначе потом этот баг придётся очень долго вылавливать
                            • 0
                              Вообще странно, что для PHP никто не делает нормального (на мой вкус и цвет) наследования шаблонов, типа:

                              base.php:
                              <html>
                              	<head>
                              		<title><?php block('title'); ?> — Хабрахабр</title>
                              		<?php block('extra_head'); ?>
                              	</head>	
                              	<body>
                              		<?php startblock('content') ?>
                              		    Что-нибудь
                              		<?php endblock() ?>	
                              	</body>
                              <html>
                              


                              post.php:
                              <?php extend('base.php') ?>
                              
                              <?php startblock('title'); ?>
                              	<?php echo $post->title ?> — Публикация
                              <?php endblock() ?>
                              
                              <?php startblock('extra_head') ?>
                              	<link rel="stylesheet" href="css/style.css"/>
                              	<script>
                              		$(function(){ doIt(); });
                              	</script>
                              <?php endblock() ?>
                              
                              <?php startblock('content') ?>
                                  <h1><? echo $post->title ?></h1>
                                  <p><? echo $post->body ?></p>
                              <?php endblock() ?>
                              


                              Контроллер:
                              class Controller_Post extends Controller\Base {
                              	$posts = new Posts();
                              	$this->output = new View('post', {'post': $posts->get($id)});
                              }
                              


                              Или я ошибаюсь?
                          • +6
                            Скорее всего этот фреймворк понравится любителям CodeIgniter/Kohana, т.к. его ноги растут именно оттуда. Достаточно открыть блоги разработчиков и посмотреть :)

                            Стоит ли использовать, не думаю, может через полгода-год когда фреймворк наберет обороты. Пока что трудно найти альтернативы проверенным yii и zend framework.
                            • 0
                              Соглашусь по поводу ZF, но как yii смог оказаться более «проверенным» чем kohana? Очень интересны критерии :-)
                              • 0
                                Вероятно проверял автор комментария :)
                              • +4
                                Очень просто, по динамике развития и отношению к разработчикам. Плотно работал с kohana года два, с yii где-то полтора, и то что я вижу в yii больше впечатляет чем в kohana-сообществе.

                                Основная проблема не в количестве фич фреймворка (в zend, yii, kohana можно просто исп. части другого), а в самом чувстве целостности фреймворка. Так в yii почти все что надо идет с коробки, ORM продумана, документация супер, все логично. В kohana же более низкий уровень, чтобы выполнить аналогичную задачу надо сделать в разы больше телодвижений, документация просто злит, в задачах посложнее 'hello word' 100% прийдется лезть в код фреймворка чтобы посмотреть почему этот метод работает не так как ожидается и т.д.

                                У kohana все происходит сумбурно, как захотел главный разработчик, так и делаем, shadowhand так и назвал себя диктатором :) Раньше перед обновлением kohana всегда скрещивал пальцы, зачастую новые фичи просто ламали уже существующий код приложения.

                                Последней каплей убившей во мне желание разрабатывать новые проекты с kohana стала концепция HMVC.
                                • –1
                                  в задачах посложнее 'hello word' 100% прийдется лезть в код фреймворка чтобы посмотреть почему этот метод работает не так как ожидается

                                  Странное мнение. Впервые о таком слышу, если честно :) Я обычно в код лезу для изучения изначальных возможностей класса или метода (да, с документацией не айс), потом же все логично и понятно.

                                  А что не так с HMVC?
                                  • +3
                                    С HMVC все нормально, но только применительно к некоторым случаям.
                                    В 99% для web достаточно обычного MVC, сам подход вызывать с кода внутренние ресурсы через URL нехорошо попахивает. Тут же сразу бродит призрак Dependency Injection да и рефакторить код с кучей прямых вызовов с параметрами самый смак :)

                                    Поэтому и отказался от HMVC. Как же быть с виджетами? Очень просто, в yii реализован прекрасный механизм виджетов с поддержкой событий, поведений.
                            • –12
                              и это всё ради <?='hello world'?>
                              • +8
                                Ну если вы на фреймворках хелловорлды пишете, то да
                              • +5
                                Очень странные какие-то примеры функций и их использования в документации:
                                set_header($name, $value) и пример его использования: Output::set_header('Content-type', 'Content-type: application/pdf');
                                Мне как-то кажется проще сразу написать header('Content-type: application/pdf');
                                Или функция send_headers(), которая, насколько я понял, повторяет родную php'шную flush().
                                Cookie::get() — очень забавная вещь. Как сказано в документации, позволяет читать переменную $_COOKIE. Интересно, что мне мешает читать ее самому.
                                Фреймворк, который вместо предоставления готовых функций и алгоритмов дает синонимы стандартным функциям, вызывает улыбку, но никак не желание его использовать.
                                • +2
                                  Не ковырялся в FUEL, но зная кое-что о Kohana, могу предположить, что set_header() предназначен для установки значения какого-то заголовка, но необязательно он будет отправлен (или он может быть изменен позже).
                                  Cookie::get() позволяет не заботиться о наличие в куках нужного ключа, передать дефолтное значение (это вообще очень полезная фича при работе с массивами). Кроме того, в Kohana куки подписываются, так что попутно происходит проверка целостности кук.

                                  В общем, не надо так вот сразу критиковать.
                                  • 0
                                    set_header не принимает аргументов и не возвращает значения, так что установку значения он не производит никак.
                                    И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).
                                    • 0
                                      set_header не принимает аргументов и не возвращает значения, так что установку значения он не производит никак.

                                      Вы уверены?
                                      И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).

                                      Я сразу полез в исходники. Метод server() использует враппер _fetch_from_array, полный аналог arr::get() из Коханы. Это уже считается «стандартным функционалом самого php»?
                                      • 0
                                        Прошу прощения, set_header, конечно же, как следует из названия, проставляет заголовок. Увлекся разглядыванием send_headers :-)
                                        Но, посмотрев тот самый исходник, на который вы дали ссылку, я так и не понял, чем разработчиков не устроил стандартный php'шный header().
                                        • 0
                                          Вероятно тем, что он не сразу отправляет заголовок ;)
                                          • +3
                                            header() тоже не сразу отправляет заголовок, а точно так же складывает заголовки в массив. Этот массив можно получить функцией headers_list(). А можно и удалить ненужный заголовок через header_remove(). Итого, имеем тот же набор функций, но минус тонну кода, потому как данные функции родные. А те, что предлагаются фреймворком, лишь перегоняют данные из одного массива в другой.
                                            • 0
                                              А вот тут соглашусь, упустил из виду. Тем не менее, не сказал бы, что это «тонна кода».
                                          • –1
                                            Тем, что он не отправляет заголовки, а только «складывает их в массив», чтобы потом отправить все разом. Но перед этим можно их ещё подредактировать/удалить лишние и т.д.
                                        • 0
                                          Собственно _fetch_from_array опять же ничего существенного не дает. Как я уже выше сказал, отлично справится на его месте тот же тернарный оператор. И это ничуть не сложнее.
                                          • –1
                                            Повторите тернарный оператор более 100 раз в проекте и убедитесь в существенности предлагаемых возможностей.
                                            • 0
                                              Какая разница, повторять 100 раз тернарный оператор или повторить 100 раз вызов функции фреймворка?
                                              • 0
                                                Вероятно тем, что в первом случае мы повторяем реализацию, а во втором — только имя функции. DRY, хоть и не в самом явном виде. Да и просто, если выбирать между
                                                $value = isset($array[$key]) ? $array[$key] : $default;

                                                и
                                                $value = arr::get($array, $key, $default);

                                                я бы выбрал второе. Хотя бы из эстетических соображений.

                                                • 0
                                                  Здесь вопрос несколько спорный на самом деле. С одной стороны, да, мы скрываем реализацию. С другой стороны сама реализация и логика настолько тривиальна, что фактически ничего мы и не скрываем.
                                                  В случае тернарного оператора мы точно так же лишь указываем, что переменная является опциональной. С точки зрения читабельности кода, мне ближе именно вариант с тернарным оператором, чем функция, коих в окружении множество.
                                                  • 0
                                                    Дайте угадаю — Вы вообще фреймворками не пользуетесь?
                                                    • 0
                                                      Тоже только что хотел спросить — вы вообще считаете фреймворки ненужными? :)
                                                      • –1
                                                        Я пользуюсь тем, что дает мне необходимый функционал, отсутствующий в готовом виде в самом интерпретаторе и его стандартных либах. Но использовать псевдофреймворк, который ничего не добавляет, а лишь увеличивает ресурсоемкость системы и только лишь добавляет синонимы к стандартным функциям, я не считаю целесообразным.
                                                        Чтобы использовать header() мне не нужен «фреймворк». Чтобы обратиться к $_COOKIE мне тоже не нужен набор классов и объектов. Другое дело, если помимо непосредственно обращения к переменной или записи значения в массив мне требуется выполнить еще с десяток операций — тогда я уже задумаюсь.
                                                        Но предложенный выше «фреймворк» ничего подобного не предоставляет. И судя по тому, что у ребят на написание синонимов 2 месяца ушло, вряд ли в ближайшие годы я смогу считать его чем-то нужным и стоящим.
                                                        • 0
                                                          Никто не заставляет Вас использовать фреймворк только для подобных вызовов. Вас вообще никто не заставляет использовать фреймворки. Только вот там помимо работы с массивами есть километр полезных действий, которые уже не придется писать руками (маршрутизация, работа с БД и т.д.).

                                                          Я не защищаю данный конкретный фреймворк, мне в принципе по барабану на FUEL, но Ваше отношение уж слишком предвзято.
                                                          • –1
                                                            Ок, работа с БД в том виде, который имеется в данном фреймворке — час кодинга.
                                                            Маршрутизация тоже далеко не великое изобретение. Она имеется в любом фреймворке. Да и в необходимом для конкретного проекта объеме она реализуется менее чем за день. Если решать вопрос маршрутизации в общем случае, я не представляю как решение, выбранное разработчиками данного фреймворка, можно реализовывать более дня-двух (с учетом того, что нужно еще и подумать, почему делаем именно так, а не иначе).

                                                            Итого имеем: никаких преимуществ перед написанием кода на чистом php без использования оберток мы не получаем, если используем FUEL. А судя по организации компонентов, их набору и времени, затраченному на разработку этого чуда, никаких преимуществ и не придвидится.
                                                            Фреймворк для тех, кому лень читать доки на php.net, но не лень потратить столько же времени на чтение доков fuel. Как-то так.
                                                            • +1
                                                              Не льстите себе — классы БД стянуты с Kohana, а там немало возможностей, и за час Вы их ну никак не реализуете. До сих пор находятся баги и предложения по дальнейшему вылизыванию данной библиотеки. Про ORM вообще молчу (хотя Вы наверное заявите, что он Вам не нужен вообще, либо в таком виде он не дает преимуществ).

                                                              Там очень много полезных библиотек свистнутых из Ko3, например cache, config, upload, validation. Да тот же MVC, в конце концов.

                                                              Не знаю, зачем я с Вами спорю, Вы ведь этот фреймворк не смотрели и не собираетесь, да и наверное никакой другой тоже. Они ведь преимуществ перед чистым php не дают
                                                              • –1
                                                                > Вы ведь этот фреймворк не смотрели и не собираетесь, да и наверное никакой другой тоже.
                                                                Представьте себе, смотрел еще как. Фреймворк полон тривиальных вещей. Единственное удобство во всем фреймворке — is_ajax(). Да, тривиальная штука, но удобная. Да, есть везде и пишется за насколько секунд, но написать is_ajax куда проще, чем проверять заголовки.
                                                                И да, ORM может быть полезной фичей в ряде задач. Но, как вы сами же сказали, оно здесь не свое-родное, так что не будет приписывать чужие достоинства данному фреймворку. В документации про работу с БД я не нашел соответствующего раздела, поэтому будем считать вопрос работы с БД открытым и этот компонент системы может быть изменен/заменен в будущем — тогда и обсудим его достоинства и недостатки.

                                                                > Они ведь преимуществ перед чистым php не дают
                                                                Я говорил про данный конкретный фреймворк, а не про любой абстрактный. Не стоит додумывать.
                                                                • +1
                                                                  Странный Вы человек :) is_ajax() является оболочкой для все того же тернарного оператора, но теперь он вдруг стал удобным…

                                                                  FUEL Вас чем-то зацепил? Он содержит в себе в принципе стандартные, возможно тривиальные компоненты (пусть и местами позаимствованные), которые есть в большинстве фреймворков, реализованы они примерно как и везде. Потому я и абстрагируюсь на Ваше отношение к фреймворкам в целом. А сам себе, да, он и мне не понравился — но причины в корне другие.
                                                                  • –1
                                                                    Справедливости ради, стоит заметить, что is_ajax — это проверка вполне конкретного заголовка на равенство константе.
                                                                    Когда я говорил про тернарный оператор, я говорил об отсутствии необходимости функции вроде get($name, $default), где необходимо передать индекс возвращаемого элемента массива. В случае is_ajax этого не требуется. Если бы в реализации is_ajax использовался бы подобный геттер (а он используется), я бы посчитал излишней такую реализацию, но не наличие самой функции. Сама функция является удобной — это не абстрактное «возьми переменную из массива», а все же вполне конкретное «запрос через ajax пришел?».
                                        • 0
                                          Кстати, для простановки дефолтных значений, как ни странно, тернарный оператор ничуть не сложнее, чем приведенные выше функции. Зато не заставляет тащить за собой некий «фреймворк».
                                          • 0
                                            Конечно, только ради этого не стоит тащить никакой фреймворк. Но ведь это не главная цель его использования, правда? А если всё равно он используется, то почему бы не воспользоваться его возможностями? Тем более никто не запрещает вам использовать тот же тернарный оператор или суперглобальные переменные напрямую, если нравится.

                                            Кстати говоря, Input::server(index) может к примеру делать очистку от XSS и прочего, или вы думаете, что авторы просто решили усложнить себе жизнь?
                                            • 0
                                              Мне кажется, для очистки от xss достаточно одной функции наподобие cleanxss($param) вместо набора из пяти функций. Кстати, насчет очистки в документации нет ни слова. Ровно как нет у этого набора функций никаких доп. параметров, которые бы сообщали о необходимости очистки, если она выполняется только при необходимости.

                                              > А если всё равно он используется, то почему бы не воспользоваться его возможностями
                                              А зачем он используется, если не предоставляет ничего нового и дополнительного, а все его возможности изначально заложены в ядро PHP (часто, с более коротким и понятным синтаксисом, более того, известным каждому разработчику, а не только имеющими опыт работы с данным фреймворком). Чтобы воспользоваться теми самыми «уникальными» возможностями, которые и без того имеются?
                                              • 0
                                                А зачем он используется, если не предоставляет ничего нового и дополнительного

                                                Вы не поверите, но фреймворки пишутся на нативном PHP, поэтому по определению не могут давать ничего «нового», а вот дополнительного и удобного дают много. По вашей логике разные обёртки над БД тоже не имеют смысла, ведь можно вместо них писать strtr(), mysql_real_escape_string() и т.д.
                                                • 0
                                                  «Нового» — я как раз таки и говорил о каком-то дополнительном функционале или удобстве. Здесь и дополнительного нет, и удобного. Сплошные синонимы стандартных функций в чуть другом виде, которая погоды ни при каких условиях не делает.
                                                  Обертки над БД по крайней мере реализуют абстракцию от самой БД и при правильной организации позволяют с легкостью сменить используемую БД. Они как раз таки и позволяют прогонять запросы через интерфейс и не задумываться об особенностях БД, чтобы защититься от инъекций или просто отправить запрос и получить данные.
                                                  Хорошая реализация обертки либо позволяет сложить с себя часть обязанностей по защите данных и их хранению, либо получить объектное представление записей из реляционной БД, к примеру.
                                                  Если вы точно не собираетесь менять БД и пишете какую-то служебную утилитку для работы с mysql, часто достаточно mysqli_*-функций.
                                                  Если вам нужно объектное отражение записей — вы используете обертку.
                                                  Если вам нужна доп. обработка запросов и данных из БД — вы опять используете обертку.
                                                  Но если вам нужно получить элемент массива $_SERVER, я не понимаю, зачем здесь нужна обертка.
                                      • +1
                                        Каскадную файловую систему, наверное, все-таки из Kohana взяли, а не из ZF?
                                        По классам/файлам действительно очень напоминает Кохану. Тот же bootstrap.php, те же фактически действия в index.php — создание основных констант путей, вызов bootstrap.php. Тот же base.php в ядре.
                                        • 0
                                          Спасибо, исправил
                                        • 0
                                          Вечерком попробую. Очень интересен принцип установки модулей.
                                          На пример: Ko3 + Smarty + Doctrine и немного расширенный view, в сумме дают неплохой эффект.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • 0
                                              <?php echo $hello; ?> легко превращается в <?=$hello?> :)
                                              • +6
                                                Не может быть! :)
                                                • –1
                                                  точно вам говорю ;) это секреты шаманов вуду по упрощению кода. только здесь и сейчас.
                                                  • +7
                                                    Или <?=SuperCMS::render('blog')?> — вуаля, блог готов!
                                                    • +3
                                                      Давно пользуюсь одной кнопкой :)
                                              • 0
                                                … ломая при этом совместимость.
                                                • 0
                                                  Совместимость с чем?
                                                  • +2
                                                    Using short tags should be avoided when developing applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control, because short tags may not be supported on the target server. For portable, redistributable code, be sure not to use short tags.

                                                    www.php.net/manual/en/language.basic-syntax.phpmode.php
                                                    • –1
                                                      Мне кажется, они не осилили <?xml… :) поэтому и выключили.
                                              • 0
                                                Код Fuel просто пропитан Кохановским запахом. Но, как и в Кохана, качественный.
                                                • +4
                                                  да уж, в некоторых файлах и копирайты от Kohana остались
                                                  github.com/fuel/fuel/blob/develop/fuel/core/classes/database/mysql.php
                                                  github.com/fuel/fuel/blob/develop/fuel/core/classes/cookie.php

                                                  • +1
                                                    Раз парни так вот решились все на php5.3 переводить, то почему не сделать по-уму и не занятся веткой 3.2 в kohana. Не думаю, что shadowhand и zombor будут очень против еще трех десятков палцев в помощь. Так как 3.1 вот-вот зарелизится, то самое время начинать разрабатывать 3.2.

                                                    Написал коммента главному разработчику по этому поводу, интересно что ответит.
                                                    • +1
                                                      А вот это очень дельная мысль! Кохана сейчас действительно развивается не теми темпами, какими хотелось бы, к сожалению. Но с другой стороны — это очень качественный фреймворк и объединив усилия вместо того чтобы распыляться, можно было бы действительно сделать его одним из лучших
                                                      • 0
                                                        Тут как знать. Я бы не сказал, что kohana развивается медленно. Ядро (именно kohana-core) очень себе стабильная штука, проверенная, сейчас допилят HMVC чтобы попрозрачней было (как Samsoir пишет тут и здесь (кстати, очень классные статьи, очень внятно, легко читается, все понятно)) ну и собственно все. Что дальше делать? Правильно, эту всю красоту в php5.3 завернуть. В ребят с Fuel’а это отлично получается.

                                                        А вот модули, да, я стабильного релиза Jelly 1.0 уже с мая жду, хотя с использованием того же Jelly у меня крутится уже несколько проектов. Что бы еще допилить? Ну да, миграции к базе данных, CLI для всего этого, а все остальное уже в модулях.

                                                        Уважая труд fuel, все таки хочу сказать что как то их сепаратизм не имеет здравого смысла. Может у них были другие свои аргументы, но они совсем не очевидны.

                                                        П.С. заметил, что много людей с сообщества Kohana (да и я сам в некоторой мере) ушли в мир Рублей и Рельсов. Вот. Нужна новая кровь.
                                                        • 0
                                                          Сразу простите за мой русский. У ребят*
                                                      • 0
                                                        Суперэбл! :)
                                                  • 0
                                                    А мне понравилось наличие в инпут-классе метода is_ajax()
                                                    Не вопрос, делается проверка за 2 секунды, но вот из-за таких мелочей иногда и нравятся некоторые продукты (-:
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                    • 0
                                                      Чем оно лучше symfony?
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • +5
                                                          А чем Zend лучше того же Yii?
                                                          • +2
                                                            холивар детектед :)
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                            • +1
                                                              А почему вы отвечаете вопросом на вопрос?Например тем, что при работе с symfony не вспоминается старый советский анекдот
                                                              — А почему дуршлаг без дырок?!
                                                              — Сам пробьёшь, небось руки не отвалятся!
                                                            • –3
                                                              а чем symfony вкуснее жёлтого фломастера?
                                                            • –3
                                                              Похож на Kohana 3 (в частности файловой структурой).
                                                              • 0
                                                                «Controller_Testdrive» — а неймспейсы что не используются, в требованиях же PHP 5.3? При этом базовый класс просто Controller, т.е. именование классов ещё и не PEAR-style. Всё понятно, дальше можно не смотреть, спасибо. Ждём релиза стабильных ZF2 и Symfony2.

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