Комментарии 123
В чем его преимущества перед другими фреймворками, например перед Yii?
Или перед «Кохана»
О преимуществах говорить пока рано, потому что фреймворк очень молодой, не было ещё ни одного релиза. Yii тоже не сразу стал таким, каким он является сейчас. Но судя по темпам разработки, иметь его ввиду всё же стоит
Кстати, одна из планируемых «модных» фич — поддержка NoSQL из коробки
Тогда — зачем он нужен?
Надо оценивать не текущее состояние, а перспективы. Предлагать свои идеи, принимать участие в создании и т.д. Это же community-driven framework, поэтому от нас с вами в том числе зависит его будущее. Хотя, пользоваться всем готовым, конечно, намного проще…
Вы у Путина учились отвечать на прямые вопросы? Давайте попробуем ещё раз. Зачем он (фреймворк, а не Путин) нужен?
Кому нужен? Вам, мне или дяде Васе? А может его авторам?
На этот вопрос каждый отвечает для себя сам
На этот вопрос каждый отвечает для себя сам
к топику/фреймворку отношения не имею. Но от снобизма подташнивает ;)
«Зачем он (фреймворк) нужен?»
Если Вам не нужен — не изучайте. Многим может быть полезен для:
— веб-разработки
— познания нового
— стырить пару удачных запчастей для своего недоделаного велосипеда
— увидеть кривые запчасти, понять что свои в своем велике тоже местами не выпрямил.
— полюбопытствовать ххх'сти-ххх'цать-ххх'м взглядом на мир
возможны и другие варианты, эти даны навскидку.
«Зачем он (фреймворк) нужен?»
Если Вам не нужен — не изучайте. Многим может быть полезен для:
— веб-разработки
— познания нового
— стырить пару удачных запчастей для своего недоделаного велосипеда
— увидеть кривые запчасти, понять что свои в своем велике тоже местами не выпрямил.
— полюбопытствовать ххх'сти-ххх'цать-ххх'м взглядом на мир
возможны и другие варианты, эти даны навскидку.
Примерно это я и пытался ответить, а меня обвинили в демагогии. Лично у меня паталогическая тяга ко всему новому, поэтому мне очень интересно наблюдать за развитием разных новых фреймворков/библиотек и т.д., плюс действительно можно почерпнуть много разных интересных идей, изучая исходники.
Кому-то другому возможно понравится его скорость, удобство или что-то ещё. Я же не могу сразу за всех ответить
Кому-то другому возможно понравится его скорость, удобство или что-то ещё. Я же не могу сразу за всех ответить
Бегло взглянув на код:
— Полная поддержка php5.3, в том числе замыкания и неймспейсы (чего крайне хочется в кохане)
— ActiveRecord
— Консоль из коробки и миграции
— Более приятные стандарты кодирования, похожие на Zend
Вообще, мне эта ситуация очень напоминает момент, когда Kohana форкнулась от Codeigniter потому что в нём не было многих новинок php5. Тут тоже самое, только версия php5.3 + стандарты кодирования более привычные для Zend — Symfony разработчиков
— Полная поддержка php5.3, в том числе замыкания и неймспейсы (чего крайне хочется в кохане)
— ActiveRecord
— Консоль из коробки и миграции
— Более приятные стандарты кодирования, похожие на Zend
Вообще, мне эта ситуация очень напоминает момент, когда Kohana форкнулась от Codeigniter потому что в нём не было многих новинок php5. Тут тоже самое, только версия php5.3 + стандарты кодирования более привычные для Zend — Symfony разработчиков
На данном этапе о преимуществах не совсем корректно говорить. Если сравнивать с Yii — нравится тенденция получения из коробки жизненно необходимых для работы модулей (email, ftp, upload). Понимаю, что это не проблема, но все-же
Давно уже присматриваюсь к этому фреймворку. Темпы разработки радуют. Обещанные возможности — тоже. Если так пойдёт и дальше — возможно попробую использовать его в реальных проектах, когда выйдет хотя бы первая стабильная версия.
Несмотря на то, что у них написано, что FuelPHP не является прямым форком ни одного существующего фреймворка, при первом ознакомлении по структуре каталогов/именовании классов очень сильно напомнил мне Кохану
Несмотря на то, что у них написано, что FuelPHP не является прямым форком ни одного существующего фреймворка, при первом ознакомлении по структуре каталогов/именовании классов очень сильно напомнил мне Кохану
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;
}
Это, конечно, некрасиво. Но можно ведь и таким образом поступить:
$view = new View('layout');
$content = new View('content/index');
$layout->content = $content->render();
$this->output = $view;
$view = new View('layout');
$content = new View('content/index');
$layout->content = $content->render();
$this->output = $view;
$view = new View('layout');
$content = new View('content/index');
$view->content = $content->render();
$this->output = $view;
$content = new View('content/index');
$view->content = $content->render();
$this->output = $view;
<?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 очень сильно способствуют разгрузке кода контроллеров.
А как по-другому вложить в один блок другой? Либо через контроллер (если есть какая-то динамика), либо внутри самого блока:
// вьюшка 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>
Погодите, а еще красивее и через статик разве нельзя?
Типа:
Типа:
$content = Array('foo' => 'bar');
$this->output = View::factory('layout', $content);
Согласен, через статик красивее. Но немножко не так. $content — это уже обработанное полноценное представление, включаемое в лайаут.
Kohana Des? ^__^
а еще красивее в content/index сделать include 'header'…
и потом искать незакрытые дивы?
если правильно верстать то ничего искать не придеться
А еще в моей любименькой IDE будет подсвечиваться ошибка!
Может предложите в один файл все писать? Мешать PHP с HTML? Дело человек говорит, а Вы язвите
Наткнулся тут. На самом деле человек говорит совершенно не дело
<?= $header ?>
Отправилось раньше
Content:
Это плохой подход, потому что хедер и футер будут выглядеть где-то так:
Header:
Footer:
Естественно, IDE будет плеваться на эту хрень. Куда лучше такой вариант
Content:
Overall:
То есть у нас есть один общий Overall, в который мы инджектим Content, а не два (Хедер+Футер), которые мы инджектим в Content. Ide не сходит с ума, мы видим, что открыто, что закрыто, и при необходимости можем подставлять разные врапперы
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 не сходит с ума, мы видим, что открыто, что закрыто, и при необходимости можем подставлять разные врапперы
Не соглашусь. Во-первых, в этом случае теряется вся прелесть каскадности (ну или придётся писать include Fuel::find_file('header')), а во-вторых, области видимости переменных хедера и всего остального объединяются, в результате чего надо будет особо пристально следить за названиями переменных, чтобы случайно что-нибудь не перезаписать. Иначе потом этот баг придётся очень долго вылавливать
Вообще странно, что для PHP никто не делает нормального (на мой вкус и цвет) наследования шаблонов, типа:
base.php:
post.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)});
}
Или я ошибаюсь?
В Yii есть.
Типа от это www.yiiframework.com/doc/guide/1.1/ru/basics.view? До того что я описал — далековато.
Или я не то нашёл?
Или я не то нашёл?
Делается вот этой штукой: www.yiiframework.com/doc/api/1.1/CClipWidget
К сожалению, в документации нет подробного описания. Как-нибудь это исправлю.
К сожалению, в документации нет подробного описания. Как-нибудь это исправлю.
В symfony или symfony2 что-то такое было, если ничего не путаю
Описанное тобой используетя в Twig — шаблонизаторе, похожем на шаблонизатор в Django (и сделанном по его мотивам). www.twig-project.org/
{% extends "layout.html" %}
{% block content %}
Content of the page...
{% endblock %}
Спасибо, крутой шаблонизатор :)
боюсь показаться занудой, но в smarty та же хрень www.smarty.net/docs/en/advanced.features.template.inheritance.tpl
Слоупок ответ :)
Есть такое наследование в Twig
Есть такое наследование в Twig
Скорее всего этот фреймворк понравится любителям CodeIgniter/Kohana, т.к. его ноги растут именно оттуда. Достаточно открыть блоги разработчиков и посмотреть :)
Стоит ли использовать, не думаю, может через полгода-год когда фреймворк наберет обороты. Пока что трудно найти альтернативы проверенным yii и zend framework.
Стоит ли использовать, не думаю, может через полгода-год когда фреймворк наберет обороты. Пока что трудно найти альтернативы проверенным yii и zend framework.
Соглашусь по поводу ZF, но как yii смог оказаться более «проверенным» чем kohana? Очень интересны критерии :-)
Вероятно проверял автор комментария :)
Очень просто, по динамике развития и отношению к разработчикам. Плотно работал с kohana года два, с yii где-то полтора, и то что я вижу в yii больше впечатляет чем в kohana-сообществе.
Основная проблема не в количестве фич фреймворка (в zend, yii, kohana можно просто исп. части другого), а в самом чувстве целостности фреймворка. Так в yii почти все что надо идет с коробки, ORM продумана, документация супер, все логично. В kohana же более низкий уровень, чтобы выполнить аналогичную задачу надо сделать в разы больше телодвижений, документация просто злит, в задачах посложнее 'hello word' 100% прийдется лезть в код фреймворка чтобы посмотреть почему этот метод работает не так как ожидается и т.д.
У kohana все происходит сумбурно, как захотел главный разработчик, так и делаем, shadowhand так и назвал себя диктатором :) Раньше перед обновлением kohana всегда скрещивал пальцы, зачастую новые фичи просто ламали уже существующий код приложения.
Последней каплей убившей во мне желание разрабатывать новые проекты с kohana стала концепция HMVC.
Основная проблема не в количестве фич фреймворка (в zend, yii, kohana можно просто исп. части другого), а в самом чувстве целостности фреймворка. Так в yii почти все что надо идет с коробки, ORM продумана, документация супер, все логично. В kohana же более низкий уровень, чтобы выполнить аналогичную задачу надо сделать в разы больше телодвижений, документация просто злит, в задачах посложнее 'hello word' 100% прийдется лезть в код фреймворка чтобы посмотреть почему этот метод работает не так как ожидается и т.д.
У kohana все происходит сумбурно, как захотел главный разработчик, так и делаем, shadowhand так и назвал себя диктатором :) Раньше перед обновлением kohana всегда скрещивал пальцы, зачастую новые фичи просто ламали уже существующий код приложения.
Последней каплей убившей во мне желание разрабатывать новые проекты с kohana стала концепция HMVC.
в задачах посложнее 'hello word' 100% прийдется лезть в код фреймворка чтобы посмотреть почему этот метод работает не так как ожидается
Странное мнение. Впервые о таком слышу, если честно :) Я обычно в код лезу для изучения изначальных возможностей класса или метода (да, с документацией не айс), потом же все логично и понятно.
А что не так с HMVC?
С HMVC все нормально, но только применительно к некоторым случаям.
В 99% для web достаточно обычного MVC, сам подход вызывать с кода внутренние ресурсы через URL нехорошо попахивает. Тут же сразу бродит призрак Dependency Injection да и рефакторить код с кучей прямых вызовов с параметрами самый смак :)
Поэтому и отказался от HMVC. Как же быть с виджетами? Очень просто, в yii реализован прекрасный механизм виджетов с поддержкой событий, поведений.
В 99% для web достаточно обычного MVC, сам подход вызывать с кода внутренние ресурсы через URL нехорошо попахивает. Тут же сразу бродит призрак Dependency Injection да и рефакторить код с кучей прямых вызовов с параметрами самый смак :)
Поэтому и отказался от HMVC. Как же быть с виджетами? Очень просто, в yii реализован прекрасный механизм виджетов с поддержкой событий, поведений.
и это всё ради <?='hello world'?>
Очень странные какие-то примеры функций и их использования в документации:
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. Интересно, что мне мешает читать ее самому.
Фреймворк, который вместо предоставления готовых функций и алгоритмов дает синонимы стандартным функциям, вызывает улыбку, но никак не желание его использовать.
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. Интересно, что мне мешает читать ее самому.
Фреймворк, который вместо предоставления готовых функций и алгоритмов дает синонимы стандартным функциям, вызывает улыбку, но никак не желание его использовать.
Не ковырялся в FUEL, но зная кое-что о Kohana, могу предположить, что set_header() предназначен для установки значения какого-то заголовка, но необязательно он будет отправлен (или он может быть изменен позже).
Cookie::get() позволяет не заботиться о наличие в куках нужного ключа, передать дефолтное значение (это вообще очень полезная фича при работе с массивами). Кроме того, в Kohana куки подписываются, так что попутно происходит проверка целостности кук.
В общем, не надо так вот сразу критиковать.
Cookie::get() позволяет не заботиться о наличие в куках нужного ключа, передать дефолтное значение (это вообще очень полезная фича при работе с массивами). Кроме того, в Kohana куки подписываются, так что попутно происходит проверка целостности кук.
В общем, не надо так вот сразу критиковать.
set_header не принимает аргументов и не возвращает значения, так что установку значения он не производит никак.
И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).
И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).
set_header не принимает аргументов и не возвращает значения, так что установку значения он не производит никак.
Вы уверены?
И я бы с вами согласился хотя бы в плане массивов, но в документации я так и не нашел ничего, что дополняло бы стандартный функционал, предоставляемый самим php. Зато нашел тьму синонимов, которые нисколько жизнь не облегчают. Ребята два месяца отказывались от обращений вида $_SERVER[index] в пользу Input::server(index).
Я сразу полез в исходники. Метод server() использует враппер _fetch_from_array, полный аналог arr::get() из Коханы. Это уже считается «стандартным функционалом самого php»?
Прошу прощения, set_header, конечно же, как следует из названия, проставляет заголовок. Увлекся разглядыванием send_headers :-)
Но, посмотрев тот самый исходник, на который вы дали ссылку, я так и не понял, чем разработчиков не устроил стандартный php'шный header().
Но, посмотрев тот самый исходник, на который вы дали ссылку, я так и не понял, чем разработчиков не устроил стандартный php'шный header().
Вероятно тем, что он не сразу отправляет заголовок ;)
header() тоже не сразу отправляет заголовок, а точно так же складывает заголовки в массив. Этот массив можно получить функцией headers_list(). А можно и удалить ненужный заголовок через header_remove(). Итого, имеем тот же набор функций, но минус тонну кода, потому как данные функции родные. А те, что предлагаются фреймворком, лишь перегоняют данные из одного массива в другой.
Тем, что он не отправляет заголовки, а только «складывает их в массив», чтобы потом отправить все разом. Но перед этим можно их ещё подредактировать/удалить лишние и т.д.
стандартный header делает то же самое. Смотрите мой комментарий выше habrahabr.ru/blogs/php/111300/#comment_3549996
Собственно _fetch_from_array опять же ничего существенного не дает. Как я уже выше сказал, отлично справится на его месте тот же тернарный оператор. И это ничуть не сложнее.
Повторите тернарный оператор более 100 раз в проекте и убедитесь в существенности предлагаемых возможностей.
Какая разница, повторять 100 раз тернарный оператор или повторить 100 раз вызов функции фреймворка?
Вероятно тем, что в первом случае мы повторяем реализацию, а во втором — только имя функции. DRY, хоть и не в самом явном виде. Да и просто, если выбирать между
и
я бы выбрал второе. Хотя бы из эстетических соображений.
$value = isset($array[$key]) ? $array[$key] : $default;и
$value = arr::get($array, $key, $default);я бы выбрал второе. Хотя бы из эстетических соображений.
Здесь вопрос несколько спорный на самом деле. С одной стороны, да, мы скрываем реализацию. С другой стороны сама реализация и логика настолько тривиальна, что фактически ничего мы и не скрываем.
В случае тернарного оператора мы точно так же лишь указываем, что переменная является опциональной. С точки зрения читабельности кода, мне ближе именно вариант с тернарным оператором, чем функция, коих в окружении множество.
В случае тернарного оператора мы точно так же лишь указываем, что переменная является опциональной. С точки зрения читабельности кода, мне ближе именно вариант с тернарным оператором, чем функция, коих в окружении множество.
Дайте угадаю — Вы вообще фреймворками не пользуетесь?
Тоже только что хотел спросить — вы вообще считаете фреймворки ненужными? :)
Я пользуюсь тем, что дает мне необходимый функционал, отсутствующий в готовом виде в самом интерпретаторе и его стандартных либах. Но использовать псевдофреймворк, который ничего не добавляет, а лишь увеличивает ресурсоемкость системы и только лишь добавляет синонимы к стандартным функциям, я не считаю целесообразным.
Чтобы использовать header() мне не нужен «фреймворк». Чтобы обратиться к $_COOKIE мне тоже не нужен набор классов и объектов. Другое дело, если помимо непосредственно обращения к переменной или записи значения в массив мне требуется выполнить еще с десяток операций — тогда я уже задумаюсь.
Но предложенный выше «фреймворк» ничего подобного не предоставляет. И судя по тому, что у ребят на написание синонимов 2 месяца ушло, вряд ли в ближайшие годы я смогу считать его чем-то нужным и стоящим.
Чтобы использовать header() мне не нужен «фреймворк». Чтобы обратиться к $_COOKIE мне тоже не нужен набор классов и объектов. Другое дело, если помимо непосредственно обращения к переменной или записи значения в массив мне требуется выполнить еще с десяток операций — тогда я уже задумаюсь.
Но предложенный выше «фреймворк» ничего подобного не предоставляет. И судя по тому, что у ребят на написание синонимов 2 месяца ушло, вряд ли в ближайшие годы я смогу считать его чем-то нужным и стоящим.
Никто не заставляет Вас использовать фреймворк только для подобных вызовов. Вас вообще никто не заставляет использовать фреймворки. Только вот там помимо работы с массивами есть километр полезных действий, которые уже не придется писать руками (маршрутизация, работа с БД и т.д.).
Я не защищаю данный конкретный фреймворк, мне в принципе по барабану на FUEL, но Ваше отношение уж слишком предвзято.
Я не защищаю данный конкретный фреймворк, мне в принципе по барабану на FUEL, но Ваше отношение уж слишком предвзято.
Ок, работа с БД в том виде, который имеется в данном фреймворке — час кодинга.
Маршрутизация тоже далеко не великое изобретение. Она имеется в любом фреймворке. Да и в необходимом для конкретного проекта объеме она реализуется менее чем за день. Если решать вопрос маршрутизации в общем случае, я не представляю как решение, выбранное разработчиками данного фреймворка, можно реализовывать более дня-двух (с учетом того, что нужно еще и подумать, почему делаем именно так, а не иначе).
Итого имеем: никаких преимуществ перед написанием кода на чистом php без использования оберток мы не получаем, если используем FUEL. А судя по организации компонентов, их набору и времени, затраченному на разработку этого чуда, никаких преимуществ и не придвидится.
Фреймворк для тех, кому лень читать доки на php.net, но не лень потратить столько же времени на чтение доков fuel. Как-то так.
Маршрутизация тоже далеко не великое изобретение. Она имеется в любом фреймворке. Да и в необходимом для конкретного проекта объеме она реализуется менее чем за день. Если решать вопрос маршрутизации в общем случае, я не представляю как решение, выбранное разработчиками данного фреймворка, можно реализовывать более дня-двух (с учетом того, что нужно еще и подумать, почему делаем именно так, а не иначе).
Итого имеем: никаких преимуществ перед написанием кода на чистом php без использования оберток мы не получаем, если используем FUEL. А судя по организации компонентов, их набору и времени, затраченному на разработку этого чуда, никаких преимуществ и не придвидится.
Фреймворк для тех, кому лень читать доки на php.net, но не лень потратить столько же времени на чтение доков fuel. Как-то так.
Не льстите себе — классы БД стянуты с Kohana, а там немало возможностей, и за час Вы их ну никак не реализуете. До сих пор находятся баги и предложения по дальнейшему вылизыванию данной библиотеки. Про ORM вообще молчу (хотя Вы наверное заявите, что он Вам не нужен вообще, либо в таком виде он не дает преимуществ).
Там очень много полезных библиотексвистнутых из Ko3, например cache, config, upload, validation. Да тот же MVC, в конце концов.
Не знаю, зачем я с Вами спорю, Вы ведь этот фреймворк не смотрели и не собираетесь, да и наверное никакой другой тоже. Они ведь преимуществ перед чистым php не дают
Там очень много полезных библиотек
Не знаю, зачем я с Вами спорю, Вы ведь этот фреймворк не смотрели и не собираетесь, да и наверное никакой другой тоже. Они ведь преимуществ перед чистым php не дают
> Вы ведь этот фреймворк не смотрели и не собираетесь, да и наверное никакой другой тоже.
Представьте себе, смотрел еще как. Фреймворк полон тривиальных вещей. Единственное удобство во всем фреймворке — is_ajax(). Да, тривиальная штука, но удобная. Да, есть везде и пишется за насколько секунд, но написать is_ajax куда проще, чем проверять заголовки.
И да, ORM может быть полезной фичей в ряде задач. Но, как вы сами же сказали, оно здесь не свое-родное, так что не будет приписывать чужие достоинства данному фреймворку. В документации про работу с БД я не нашел соответствующего раздела, поэтому будем считать вопрос работы с БД открытым и этот компонент системы может быть изменен/заменен в будущем — тогда и обсудим его достоинства и недостатки.
> Они ведь преимуществ перед чистым php не дают
Я говорил про данный конкретный фреймворк, а не про любой абстрактный. Не стоит додумывать.
Представьте себе, смотрел еще как. Фреймворк полон тривиальных вещей. Единственное удобство во всем фреймворке — is_ajax(). Да, тривиальная штука, но удобная. Да, есть везде и пишется за насколько секунд, но написать is_ajax куда проще, чем проверять заголовки.
И да, ORM может быть полезной фичей в ряде задач. Но, как вы сами же сказали, оно здесь не свое-родное, так что не будет приписывать чужие достоинства данному фреймворку. В документации про работу с БД я не нашел соответствующего раздела, поэтому будем считать вопрос работы с БД открытым и этот компонент системы может быть изменен/заменен в будущем — тогда и обсудим его достоинства и недостатки.
> Они ведь преимуществ перед чистым php не дают
Я говорил про данный конкретный фреймворк, а не про любой абстрактный. Не стоит додумывать.
Странный Вы человек :) is_ajax() является оболочкой для все того же тернарного оператора, но теперь он вдруг стал удобным…
FUEL Вас чем-то зацепил? Он содержит в себе в принципе стандартные, возможно тривиальные компоненты (пусть и местами позаимствованные), которые есть в большинстве фреймворков, реализованы они примерно как и везде. Потому я и абстрагируюсь на Ваше отношение к фреймворкам в целом. А сам себе, да, он и мне не понравился — но причины в корне другие.
FUEL Вас чем-то зацепил? Он содержит в себе в принципе стандартные, возможно тривиальные компоненты (пусть и местами позаимствованные), которые есть в большинстве фреймворков, реализованы они примерно как и везде. Потому я и абстрагируюсь на Ваше отношение к фреймворкам в целом. А сам себе, да, он и мне не понравился — но причины в корне другие.
Справедливости ради, стоит заметить, что is_ajax — это проверка вполне конкретного заголовка на равенство константе.
Когда я говорил про тернарный оператор, я говорил об отсутствии необходимости функции вроде get($name, $default), где необходимо передать индекс возвращаемого элемента массива. В случае is_ajax этого не требуется. Если бы в реализации is_ajax использовался бы подобный геттер (а он используется), я бы посчитал излишней такую реализацию, но не наличие самой функции. Сама функция является удобной — это не абстрактное «возьми переменную из массива», а все же вполне конкретное «запрос через ajax пришел?».
Когда я говорил про тернарный оператор, я говорил об отсутствии необходимости функции вроде get($name, $default), где необходимо передать индекс возвращаемого элемента массива. В случае is_ajax этого не требуется. Если бы в реализации is_ajax использовался бы подобный геттер (а он используется), я бы посчитал излишней такую реализацию, но не наличие самой функции. Сама функция является удобной — это не абстрактное «возьми переменную из массива», а все же вполне конкретное «запрос через ajax пришел?».
Кстати, для простановки дефолтных значений, как ни странно, тернарный оператор ничуть не сложнее, чем приведенные выше функции. Зато не заставляет тащить за собой некий «фреймворк».
Конечно, только ради этого не стоит тащить никакой фреймворк. Но ведь это не главная цель его использования, правда? А если всё равно он используется, то почему бы не воспользоваться его возможностями? Тем более никто не запрещает вам использовать тот же тернарный оператор или суперглобальные переменные напрямую, если нравится.
Кстати говоря, Input::server(index) может к примеру делать очистку от XSS и прочего, или вы думаете, что авторы просто решили усложнить себе жизнь?
Кстати говоря, Input::server(index) может к примеру делать очистку от XSS и прочего, или вы думаете, что авторы просто решили усложнить себе жизнь?
Мне кажется, для очистки от xss достаточно одной функции наподобие cleanxss($param) вместо набора из пяти функций. Кстати, насчет очистки в документации нет ни слова. Ровно как нет у этого набора функций никаких доп. параметров, которые бы сообщали о необходимости очистки, если она выполняется только при необходимости.
> А если всё равно он используется, то почему бы не воспользоваться его возможностями
А зачем он используется, если не предоставляет ничего нового и дополнительного, а все его возможности изначально заложены в ядро PHP (часто, с более коротким и понятным синтаксисом, более того, известным каждому разработчику, а не только имеющими опыт работы с данным фреймворком). Чтобы воспользоваться теми самыми «уникальными» возможностями, которые и без того имеются?
> А если всё равно он используется, то почему бы не воспользоваться его возможностями
А зачем он используется, если не предоставляет ничего нового и дополнительного, а все его возможности изначально заложены в ядро PHP (часто, с более коротким и понятным синтаксисом, более того, известным каждому разработчику, а не только имеющими опыт работы с данным фреймворком). Чтобы воспользоваться теми самыми «уникальными» возможностями, которые и без того имеются?
А зачем он используется, если не предоставляет ничего нового и дополнительного
Вы не поверите, но фреймворки пишутся на нативном PHP, поэтому по определению не могут давать ничего «нового», а вот дополнительного и удобного дают много. По вашей логике разные обёртки над БД тоже не имеют смысла, ведь можно вместо них писать strtr(), mysql_real_escape_string() и т.д.
«Нового» — я как раз таки и говорил о каком-то дополнительном функционале или удобстве. Здесь и дополнительного нет, и удобного. Сплошные синонимы стандартных функций в чуть другом виде, которая погоды ни при каких условиях не делает.
Обертки над БД по крайней мере реализуют абстракцию от самой БД и при правильной организации позволяют с легкостью сменить используемую БД. Они как раз таки и позволяют прогонять запросы через интерфейс и не задумываться об особенностях БД, чтобы защититься от инъекций или просто отправить запрос и получить данные.
Хорошая реализация обертки либо позволяет сложить с себя часть обязанностей по защите данных и их хранению, либо получить объектное представление записей из реляционной БД, к примеру.
Если вы точно не собираетесь менять БД и пишете какую-то служебную утилитку для работы с mysql, часто достаточно mysqli_*-функций.
Если вам нужно объектное отражение записей — вы используете обертку.
Если вам нужна доп. обработка запросов и данных из БД — вы опять используете обертку.
Но если вам нужно получить элемент массива $_SERVER, я не понимаю, зачем здесь нужна обертка.
Обертки над БД по крайней мере реализуют абстракцию от самой БД и при правильной организации позволяют с легкостью сменить используемую БД. Они как раз таки и позволяют прогонять запросы через интерфейс и не задумываться об особенностях БД, чтобы защититься от инъекций или просто отправить запрос и получить данные.
Хорошая реализация обертки либо позволяет сложить с себя часть обязанностей по защите данных и их хранению, либо получить объектное представление записей из реляционной БД, к примеру.
Если вы точно не собираетесь менять БД и пишете какую-то служебную утилитку для работы с mysql, часто достаточно mysqli_*-функций.
Если вам нужно объектное отражение записей — вы используете обертку.
Если вам нужна доп. обработка запросов и данных из БД — вы опять используете обертку.
Но если вам нужно получить элемент массива $_SERVER, я не понимаю, зачем здесь нужна обертка.
Каскадную файловую систему, наверное, все-таки из Kohana взяли, а не из ZF?
По классам/файлам действительно очень напоминает Кохану. Тот же bootstrap.php, те же фактически действия в index.php — создание основных констант путей, вызов bootstrap.php. Тот же base.php в ядре.
По классам/файлам действительно очень напоминает Кохану. Тот же bootstrap.php, те же фактически действия в index.php — создание основных констант путей, вызов bootstrap.php. Тот же base.php в ядре.
Вечерком попробую. Очень интересен принцип установки модулей.
На пример: Ko3 + Smarty + Doctrine и немного расширенный view, в сумме дают неплохой эффект.
На пример: Ko3 + Smarty + Doctrine и немного расширенный view, в сумме дают неплохой эффект.
НЛО прилетело и опубликовало эту надпись здесь
<?php echo $hello; ?> легко превращается в <?=$hello?> :)
Не может быть! :)
… ломая при этом совместимость.
Совместимость с чем?
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
Код Fuel просто пропитан Кохановским запахом. Но, как и в Кохана, качественный.
да уж, в некоторых файлах и копирайты от Kohana остались
github.com/fuel/fuel/blob/develop/fuel/core/classes/database/mysql.php
github.com/fuel/fuel/blob/develop/fuel/core/classes/cookie.php
github.com/fuel/fuel/blob/develop/fuel/core/classes/database/mysql.php
github.com/fuel/fuel/blob/develop/fuel/core/classes/cookie.php
Раз парни так вот решились все на php5.3 переводить, то почему не сделать по-уму и не занятся веткой 3.2 в kohana. Не думаю, что shadowhand и zombor будут очень против еще трех десятков палцев в помощь. Так как 3.1 вот-вот зарелизится, то самое время начинать разрабатывать 3.2.
Написал коммента главному разработчику по этому поводу, интересно что ответит.
Написал коммента главному разработчику по этому поводу, интересно что ответит.
А вот это очень дельная мысль! Кохана сейчас действительно развивается не теми темпами, какими хотелось бы, к сожалению. Но с другой стороны — это очень качественный фреймворк и объединив усилия вместо того чтобы распыляться, можно было бы действительно сделать его одним из лучших
Тут как знать. Я бы не сказал, что kohana развивается медленно. Ядро (именно kohana-core) очень себе стабильная штука, проверенная, сейчас допилят HMVC чтобы попрозрачней было (как Samsoir пишет тут и здесь (кстати, очень классные статьи, очень внятно, легко читается, все понятно)) ну и собственно все. Что дальше делать? Правильно, эту всю красоту в php5.3 завернуть. В ребят с Fuel’а это отлично получается.
А вот модули, да, я стабильного релиза Jelly 1.0 уже с мая жду, хотя с использованием того же Jelly у меня крутится уже несколько проектов. Что бы еще допилить? Ну да, миграции к базе данных, CLI для всего этого, а все остальное уже в модулях.
Уважая труд fuel, все таки хочу сказать что как то их сепаратизм не имеет здравого смысла. Может у них были другие свои аргументы, но они совсем не очевидны.
П.С. заметил, что много людей с сообщества Kohana (да и я сам в некоторой мере) ушли в мир Рублей и Рельсов. Вот. Нужна новая кровь.
А вот модули, да, я стабильного релиза Jelly 1.0 уже с мая жду, хотя с использованием того же Jelly у меня крутится уже несколько проектов. Что бы еще допилить? Ну да, миграции к базе данных, CLI для всего этого, а все остальное уже в модулях.
Уважая труд fuel, все таки хочу сказать что как то их сепаратизм не имеет здравого смысла. Может у них были другие свои аргументы, но они совсем не очевидны.
П.С. заметил, что много людей с сообщества Kohana (да и я сам в некоторой мере) ушли в мир Рублей и Рельсов. Вот. Нужна новая кровь.
Суперэбл! :)
А мне понравилось наличие в инпут-классе метода is_ajax()
Не вопрос, делается проверка за 2 секунды, но вот из-за таких мелочей иногда и нравятся некоторые продукты (-:
Не вопрос, делается проверка за 2 секунды, но вот из-за таких мелочей иногда и нравятся некоторые продукты (-:
НЛО прилетело и опубликовало эту надпись здесь
Похож на Kohana 3 (в частности файловой структурой).
«Controller_Testdrive» — а неймспейсы что не используются, в требованиях же PHP 5.3? При этом базовый класс просто Controller, т.е. именование классов ещё и не PEAR-style. Всё понятно, дальше можно не смотреть, спасибо. Ждём релиза стабильных ZF2 и Symfony2.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FuelPHP — фреймворк с полным баком