Comments 68
Хм, много интересных вещей там есть, и удобных, но очень не понравился подход, когда на каждую глобальную сущность у них свой класс, в котором куча static методов. Хотелось бы одну общую точку, например как в Yii, Yii::app()->… а тут много-много всего самостоятельного статичного. Ну и еще немного не понравились nested controllers, это значит если я хочу вложенность в 3-4 сделать, то это будет One_Two_Thre_Four_Controller, прям как имена ZF :D Но в целом понравился) Надеюсь другие разработчики, в том числе Yii, возьмут отсюда тоже много классных идей)
По сути это может стать альтернативой YII. Уж больно они тянут со своей 2-ой веткой, а тут есть все что хотят реализовать в Yii. Хотя я все равно не вижу никаких реальных доводов для того что бы использовать этот фреймворк. Как по мне ближайшее время вряд-ли что-то круче симфонии второй появится.
Хм, не соглашусь с вами насчет «реальных доводов для того что бы использовать этот фреймворк», пусть посмотрел бегло, но все же у этого fw есть много полезных вещей и хорошая структура, что в сумме даст ускорение + улушчение качества разработки, разве это не основополагающе? Вопрос в том, что есть подсознательное «не хочу учить что-то новое», но это уже другие проблемы :)
Беда в том что я лично не увидел ничего нового и ничего «лучше». В симфони есть те же бандлы, тот же Dependency injection и т.д. И реализация там много более интересна (хотя бы аннотации, раутинг и прочие плюшки, которые здесь реализованы довольно стандартно.
The Eloquent ORM и миграции. Мне больше по душе Doctrine ORM. Я пользовался многими и субьективно, лично для себя, ничего лучше я просто не нашел. Апдейт схемы делает наличие миграций необязательными. Очень редко они мне были нужны. Вообще все намного более лаконично. Поправил модель, закомитил. Другой человек обновил у себя, выполнил команду и готово. А так после изменения модели приходится и миграцию писать. Я ленивый человек и не люблю лишние телодвижения для достижения желаемой цели. Да и AR любит память жрать. Тут к слову было бы неплохо разработчикам фреймворка подготовить какой-нибудь бенчмарк.
no-sql из коробки — ну… клево, да. Правда у Doctrine тоже есть ODM.
Обширная коллекция бандлов — чуть менее 100. Большая часть из которых лишь сервисы для DI. На то он и DI что бы можно было легко любую библиотеку в сервис превратить.
Подытожив: я не буду пользоваться этим фреймворком. Покрайнемере пока не увижу явных плюсов перед симфони 2. Ну или по работе придется.
p.s. Я сам был приверженцем Yii, но по работе заставили разбираться с Symfony 2. По началу да, плевался, но затем… словом, как я уже говорил, врят-ли ближайшее время появится что-то кардинально новое.
The Eloquent ORM и миграции. Мне больше по душе Doctrine ORM. Я пользовался многими и субьективно, лично для себя, ничего лучше я просто не нашел. Апдейт схемы делает наличие миграций необязательными. Очень редко они мне были нужны. Вообще все намного более лаконично. Поправил модель, закомитил. Другой человек обновил у себя, выполнил команду и готово. А так после изменения модели приходится и миграцию писать. Я ленивый человек и не люблю лишние телодвижения для достижения желаемой цели. Да и AR любит память жрать. Тут к слову было бы неплохо разработчикам фреймворка подготовить какой-нибудь бенчмарк.
no-sql из коробки — ну… клево, да. Правда у Doctrine тоже есть ODM.
Обширная коллекция бандлов — чуть менее 100. Большая часть из которых лишь сервисы для DI. На то он и DI что бы можно было легко любую библиотеку в сервис превратить.
Подытожив: я не буду пользоваться этим фреймворком. Покрайнемере пока не увижу явных плюсов перед симфони 2. Ну или по работе придется.
p.s. Я сам был приверженцем Yii, но по работе заставили разбираться с Symfony 2. По началу да, плевался, но затем… словом, как я уже говорил, врят-ли ближайшее время появится что-то кардинально новое.
Да, полностью согласен по поводу Symfony и без упрека в сторону Laravel. Сейчас пишем проект на Symfony 2.3 — полностью покрывает все необходимое в разработке — (Хотя часто вижу высказывания, что порог вхождения в Symfony высокий — я думаю просто нужно привыкнуть к тому, что можно получить все через DI). И по поводу аннотаций — просто сказка. Нужно ACL повесить над роутингом — пожалуйста, добавляем в аннотацию и все (предварительно подключив бандл JMSSecurityExtraBundle ).
«recovery mode» на хабре…
Так и думал что напишут про этот фреймворк :)
Так и думал что напишут про этот фреймворк :)
Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.
Паттерн Active record был описан в 2003-ем году, когда как RoR вышла в 2004-ом. Объясните же мне, почему все слизано именно с RoR?
Потому что ActiveRecord – это не только название паттерна, но также и название библиотеки Rails. И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.
Гениальное логическое умозаключение. Я так подозреваю, что если в рельсах есть Controller, то в остальных fw на других ЯП, в которых есть данный тип объектов, тоже все слизано с рельс? мда…
При чем тут слизано? Вы слышали про термин «контекст употребления»? В зависимости от контекста это имя собственное может значить либо одно, либо другое. В примере сверху очевидно, что речь шла про _библиотеку_, а не про паттерн. Но конечно легче троллить и умничать, чем знать о существовании и того, и другого.
K чему наезд?
«И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.» — это же тонкий стеб над «Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.».
«И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.» — это же тонкий стеб над «Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.».
Когда уже сделают чтобы людей подписанных на ruby не пускали в php хабы.
Я так и не понял, чем-же этот фреймворк круче Symfony или других фреймворков? Например при задании в поиске тупо: «i18n» мне ничего не выпало? Получается, интернационализация отсутствует? Хорошо, а ОРМ взяли откуда — контрол+це, контрол+ве? Редис?! Он типа везде стоит как дефолт, правда? И что-же получается? Как всегда, фреймворк для быстрого написания (говно)кода, чтобы код веб странички не выглядел как говнокод и не казался слишком «гламурно-тупым» для новичков? Зато да, используете «фреймворк».
Или я чего-то не усёк?
ПС: я так, маслица в огонёк подлил. Если чё, минусуя обьяснайте в чём не прав…
Или я чего-то не усёк?
ПС: я так, маслица в огонёк подлил. Если чё, минусуя обьяснайте в чём не прав…
Каждый новый FW теперь обязан быть круче Symfony или других фреймворков?
Как сегодня было сказано в одном из топиков:
Как сегодня было сказано в одном из топиков:
это всего лишь дело вкуса
Дело вкуса это конечно хорошо, но обычно выбирают инструменты все же для работы. А для работы важно что бы это работало. Причем желательно что бы и через год фреймворк развивался, поддерживался, количество расширений росло. Рассматриваются перспективы, качество реализации и т.д. и т.п.
Рассматривая этот фреймворк я не увидел у него перспективы роста. Он никак не обгонит симфони, ставшей мейнстримом. Посему для реализации проекта я выберу симфони, так как в будущем, если вдруг я уже не буду иметь к проекту никакого отношения, найти человека, который будет в дальнейшем поддерживать код, не составит труда.
Вот если бы у этого фреймворка была более узкая целевая аудитория, или же он позволял реализовывать какие-то задачи на порядок быстрее, то я бы с удовольствием рассмотрел этот вариант.
Почему никто не сделает нормальный человеческий демон на PHP? (их уже много конечно, но тут развернуться в плане возможностей и альтернатив есть куда) Ну или там, аналог CoffeeScript для php (какие-нибудь надстройки, синтаксический сахар, нормальные названия методов, функций и прочего) для более удобной и функциональной разработки? (в симфони вот ввели аннотации, которые, судя по всему, в сам язык введут ой как не скоро, если вообще введут)
Рассматривая этот фреймворк я не увидел у него перспективы роста. Он никак не обгонит симфони, ставшей мейнстримом. Посему для реализации проекта я выберу симфони, так как в будущем, если вдруг я уже не буду иметь к проекту никакого отношения, найти человека, который будет в дальнейшем поддерживать код, не составит труда.
Вот если бы у этого фреймворка была более узкая целевая аудитория, или же он позволял реализовывать какие-то задачи на порядок быстрее, то я бы с удовольствием рассмотрел этот вариант.
Почему никто не сделает нормальный человеческий демон на PHP? (их уже много конечно, но тут развернуться в плане возможностей и альтернатив есть куда) Ну или там, аналог CoffeeScript для php (какие-нибудь надстройки, синтаксический сахар, нормальные названия методов, функций и прочего) для более удобной и функциональной разработки? (в симфони вот ввели аннотации, которые, судя по всему, в сам язык введут ой как не скоро, если вообще введут)
С таким подходом:
Sinatra не нужен в мире Ruby, поскольку RoR – мейнстрим.
Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе.
Play не нужен в Java – нафига, уже есть Spring.
Продолжать?
Sinatra не нужен в мире Ruby, поскольку RoR – мейнстрим.
Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе.
Play не нужен в Java – нафига, уже есть Spring.
Продолжать?
Ваша цепочка не совсем корректна:
Я хоть и далек от рабби, но синатра больше похожа на микрофреймворк. А вот RoR — тормознутый монстр (извините за бестактность, быть может мои впечатления устарели). Цели использования у них изначально разные, разные целевые группы. Тут все гуд.
Mootools сравнивать с jQuery тоже несколько некоректно. Если вы выбираете библиотеку для работы с DOM то да, mootools вам не нужен. Но если вы пишите сложное приложение то вам понадобится более мение удобная структура. Хотя сейчас есть backbone+underscore+jquery.
кофескрипт — тут я промолчу. Лично мне он никогда не нравился, потому субьективно я настроен против. Хоть и понимаю что штука возможно полезная.
Play и Spring не видел. С Java знаком лишь на уровне универа. Мне больше как-то C# подуше.
Я не призываю остановить развитие так как есть какой-то модный фреймворк. Все развивается, и в один момент фреймворк может уже не соответствовать требованиям. Я о том, что если фреймворк ничем не лучше при той же сфере применения — он не особо нужен.
Я хоть и далек от рабби, но синатра больше похожа на микрофреймворк. А вот RoR — тормознутый монстр (извините за бестактность, быть может мои впечатления устарели). Цели использования у них изначально разные, разные целевые группы. Тут все гуд.
Mootools сравнивать с jQuery тоже несколько некоректно. Если вы выбираете библиотеку для работы с DOM то да, mootools вам не нужен. Но если вы пишите сложное приложение то вам понадобится более мение удобная структура. Хотя сейчас есть backbone+underscore+jquery.
кофескрипт — тут я промолчу. Лично мне он никогда не нравился, потому субьективно я настроен против. Хоть и понимаю что штука возможно полезная.
Play и Spring не видел. С Java знаком лишь на уровне универа. Мне больше как-то C# подуше.
Я не призываю остановить развитие так как есть какой-то модный фреймворк. Все развивается, и в один момент фреймворк может уже не соответствовать требованиям. Я о том, что если фреймворк ничем не лучше при той же сфере применения — он не особо нужен.
Я не смотрел и не щупал сабж, возможно, там все плохо, а может быть есть и свои плюшки.
Да тот же symfony для решения многих задач избыточен, и хотелось бы иметь что-то полегче и шустрее.
А выбор — это же здорово, глядишь и получится что-то такое, что все скажут wow.
PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)
Да тот же symfony для решения многих задач избыточен, и хотелось бы иметь что-то полегче и шустрее.
А выбор — это же здорово, глядишь и получится что-то такое, что все скажут wow.
PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)
Да, не спорю, симфони зачастую избыточен. Как допустим использование MySQL там, где хватило бы обычных файлов ну или хотя бы простенькое NoSQL Хранилище. Есть множество микро-фреймворков. Тот же Silex, который построен на симфони. Да много их разных. Но ведь и сабж избыточен. Так зачем он мне? у меня уже есть неплохой фреймворк который с лихвой покрывает все мои нужды. Мне вообще концепция узконаправленных библиотек нравится, и не радует меня попутки реализовать универсальную систему. Чем мне нравится симфони, и пожалуй это ее основное преимущество, ты не привязываешь компоненты системы к архитектуре фреймворка. Это делает все очень гибким.
Я заслужил… чего уж там.
PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)
Я заслужил… чего уж там.
Мейнстрим хорош тем, что вам не придется писать много документации и объяснять новичкам особенности своих хипстерских фреймворков. Симфонист разберется в симфони проекте гораздо быстрее, чем в laravel проекте и т.п.
Фреймворк это набор реализованных паттернов. И говорить о гибкости как-то странно. Все равно рано или поздно что-то придется допиливать самим.
Фреймворк это набор реализованных паттернов. И говорить о гибкости как-то странно. Все равно рано или поздно что-то придется допиливать самим.
Истина, как всегда, где-то посередине: руби раби рабби
=)
=)
UFO just landed and posted this here
В буржунете сейчас идет волна ня-обожания Laravel, особенно после поста philsturgeon.co.uk/blog/2012/05/laravel-is-awesome. (Fuelphp, кстати, впал в немилось, из-за планируемого перехода на PSR-1 с кемел-кейсом, и вообще он уже не ня). И такое ощущение, что народ не видел Кохану вообще. Почти никто её не вспоминает и не сравнивает с ней. Такое ощущение, что все до сих пор сидят на CodeIgniter и отсутствие singleton для них уже мегапрорыв и разрыв шаблонов.
Интересно, почему Кохана растеряла всех codeigniter-свитчеров? Ведь это прекрасный простой (если не лезть в глубь и работать по шаблону) фреймворк, как раз для ЦА laravel?
Интересно, почему Кохана растеряла всех codeigniter-свитчеров? Ведь это прекрасный простой (если не лезть в глубь и работать по шаблону) фреймворк, как раз для ЦА laravel?
Слишком частое изменение API, не совместимые с предыдущими версиями. Например, код под 3.1 не будет работать на 3.0. Плюс, не поспевает документация, мало наработок (это уже следствие изменения апи), игнор девелоперов со стороны разработчиков фреймворка и т.д.
UFO just landed and posted this here
А до этого, с 3.0 на 3.1, меняли Validate на Validation + Valid, вводили Request — это довольно обширные изменения были. brotkin.ru/2011/01/10/ko-31-rc1
В 3.1 появился response, изменилась валидация, пропали фильтры и callback-и в валидации (которые, между прочим, часто использовались).
В 3.2 изменились конфиги, изменился request (например, пропал метод url), кое-какие мелкие изменения.
В 3.3 изменились Controller, HMVC, HTTP_Exception (это вообще весело), request (снова! пропал redirect, изменились параметры в factory, пропал response), Autoload (!!! вообще ломающий старый код) и т.д.
В общем, каждое обновление ломает рабочий код (
В 3.2 изменились конфиги, изменился request (например, пропал метод url), кое-какие мелкие изменения.
В 3.3 изменились Controller, HMVC, HTTP_Exception (это вообще весело), request (снова! пропал redirect, изменились параметры в factory, пропал response), Autoload (!!! вообще ломающий старый код) и т.д.
В общем, каждое обновление ломает рабочий код (
UFO just landed and posted this here
Раньше у Фила была другая работа — разрабатывать CodeIgniter и FuelPHP. Поэтому такой вот поклон в адрес прямого конкурента людей поразил.
UFO just landed and posted this here
На самом деле это это был не столько поклон, сколько оправдание неповоротливости CodeIgniter в плане технологических улучшений — ведь и правда, вносить кардинальные изменения в движок, которые ломают функциональность работающих приложений, — это проявление неуважения к пользователям продукта. Кстати, сабж на протяжении трёх версий менялся кардинально, но это можно списать на его молодость.
Запоздало влез, но да, Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе. Тут полностью согласен, не нужны они там. Про остальные технологии не знаю.
«каждый защищает свое г**но» — тут уже больше дело вкуса… так как есть люди для которых Zend круче всего на свете, у других это Yii и т.д. по списку. Говно можно писать и на Symfony, и на всех остальных, так что, не нужно тут поднимать шуму, или быть уверенным что есть FW который не даст написать говно-код.
Интернационализация там есть.
Он не круче, он проще. Если Symfony это RoR, то Laravel скорее Sinatra. Taylor Otwell его начал писать год назад, чтобы с чистого листа сделать простой и человечный php-фреймворк, без груза обратной совместимости и с радостями 5.3 (а именно замыкания) и наработок из RoR и других фреймворков. Получилось в целом неплохо. Это для людей, которые начинали не с Zend, а с Codeigniter. Для ремесленников, а не для живописцев.
Он не круче, он проще. Если Symfony это RoR, то Laravel скорее Sinatra. Taylor Otwell его начал писать год назад, чтобы с чистого листа сделать простой и человечный php-фреймворк, без груза обратной совместимости и с радостями 5.3 (а именно замыкания) и наработок из RoR и других фреймворков. Получилось в целом неплохо. Это для людей, которые начинали не с Zend, а с Codeigniter. Для ремесленников, а не для живописцев.
Перевод некоторых статей на русский: laravel.ru/
Полезные ресурсы и ссылки для quick start: laravel.ru/forum/viewtopic.php?id=16
Про laravel обещал написать Александр Макаров (Sam Dark), один из разработчиков Yii. C вот такой вот затравкой, опубликованной неделю назад в твиттере:
«Смотрю фреймворк laravel. Некоторые штуки красивы, но есть и фатальные для выстраиваемых на нём приложений ошибки.»
Полезные ресурсы и ссылки для quick start: laravel.ru/forum/viewtopic.php?id=16
Про laravel обещал написать Александр Макаров (Sam Dark), один из разработчиков Yii. C вот такой вот затравкой, опубликованной неделю назад в твиттере:
«Смотрю фреймворк laravel. Некоторые штуки красивы, но есть и фатальные для выстраиваемых на нём приложений ошибки.»
UFO just landed and posted this here
Так и не встретил раздела «Итак, фатальные для меня штуки». А было бы интересно.
Самые фатальные в разделе «ORM, из нехорошего» + излишнее использование статики.
«Массовое присвоение в ORM включено по умолчанию».
В условиях необязательной валидации в моделях разработчик теоретически может выстрелить себе в ногу. Понятно, что с нашей точки зрения он сам себе кузнец своего счастья, но с точки разработчика фреймворков это серьезная уязвимость.
В условиях необязательной валидации в моделях разработчик теоретически может выстрелить себе в ногу. Понятно, что с нашей точки зрения он сам себе кузнец своего счастья, но с точки разработчика фреймворков это серьезная уязвимость.
Имеет право на жизнь! Однако от статьи я ожидал раскрытия темы, примеров кода, примеров приложений/сайтов исполненных на данном FW. А так… просто ссылка: Тут вот такое появилось — сходите по ссылке…
Кстати, примеры есть на завлекательном лэндинге getlaravel.com
UFO just landed and posted this here
HMVC есть, он добавляется бандлом: bundles.laravel.com/bundle/hmvc
их ОРМ (Eloquent) очень кривой. например вот как работает eager loading:
Та же кохана делает такое одним запросом с лефт джойнами.
Представте себе теперь что у вас 10000 books, в случае ларавел алогоритм выберет все 10000, пройдет по ним, соберет айдишки, создаст запрос с айдишками через кому (кстати если если нужно поддгрузить больше связей то запросов будет больше, и учтите что есть ограничение на размер параметров в IN ), потом пройдется по масивам еще раз и соединит books и authors. Памяти выжрет вагон.
Вот в той же PHPixie о которой я писал создатся один запрос с джойнами и в памяти всегда будет только 1 книга и ее автор (так как будет использоватся курсор для прохода по строчкам резульата запроса).
foreach (Book::with('author')->get() as $book)
{
echo $book->author->name;
}
In the loop above, only two queries will be executed:
select * from books
select * from authors where id in (1, 2, 3, 4, 5, ...)
Та же кохана делает такое одним запросом с лефт джойнами.
Представте себе теперь что у вас 10000 books, в случае ларавел алогоритм выберет все 10000, пройдет по ним, соберет айдишки, создаст запрос с айдишками через кому (кстати если если нужно поддгрузить больше связей то запросов будет больше, и учтите что есть ограничение на размер параметров в IN ), потом пройдется по масивам еще раз и соединит books и authors. Памяти выжрет вагон.
Вот в той же PHPixie о которой я писал создатся один запрос с джойнами и в памяти всегда будет только 1 книга и ее автор (так как будет использоватся курсор для прохода по строчкам резульата запроса).
Боже! Жги напалмом!
Ибо все серьёзно обсуждают сорта этих поделок.
Sign up to leave a comment.
Laravel — PHP Framework для ремесленников