Yii2 будет на PHP 5.4
20 октября 2013
Ещё недавно я рассказывал про то, что Yii2 будет использовать PHP 5.3, и вот планы круто поменялись. После публичного обсуждения, а затем и внутрикомандного, было решено, что релиз состоится с минимальным требованием PHP 5.4.
Сначала мы составили список популярных хостингов. После этого стало понятно, что 72% хостингов, которые поддерживают минимальную на тот момент версию 5.3.7, поддерживают и 5.4. А те, что принципиально застряли на 5.2 или 5.3, чаще всего не имеют и 5.3.7. С операционками выходит примерно так же.
Далее пошли в ход плюсы.
Короткий синтаксис массивов и <?=
в шаблонах. Да, для фреймворка оно не нужно и это долгое время было аргументом против 5.4. Но мы изначально упустили из вида, что авторам расширений придётся использовать 5.4, что негативно скажется на сообществе.
В 5.3 более не исправляется, начиная с этого Июля. В Июле 2014 PHP 5.3 перестанет получать также и исправления по части безопасности, так что использовать его будет довольно рисково. К тому времени Yii2, как раз, должен начать набирать обороты и если сейчас переход на 5.4 кажется немного рисковым, то через пол года это точно будет верным шагом. Да и с точки зрения маркетинга шаг верный.
Ну и трейты, конечно. Хотя на их счёт ещё есть большие сомнения...
Комментарии RSS по email OK
Эх, ещё б неймспесы с большой буквы... А так ждём-с, да.
JhaoDa, зачем?
Очень правильное решение. Очень-очень ждём. Александр, есть ли какие- либо пргнозы, когда ожидать бету? Скоро начинать новый проект, релиз планируется где-то весной-летом следующего года. Будет ли Yii2 верным решением?
Конечно 5.4, молодцы, правильное решение.
Да и 5.4 быстрее и памяти меньше ест
Большинство популярных библиотек на PHP, которые я видел, в пространствах имен используют UpperCamelCase.
Так что, как минимум, не хочется что бы в коде была такая разношерстность.
Правильное решение! Теперь вас ожидает очередной виток рефакторинга по внедрению примесей :)
В обсуждении на гите если почитать, то qiangxue озвучил, что не будет значительных изменений в связи с трейтами, не считая внутренней работы с AR. Хотя этот момент смены архитектуры и API обязательно нуждается в прояснении. Сейчас получается что обратная несовместимость с пхп 5.3. сделана только из-за синтаксиса массивов и короткого echo тега, что малосущественные внутренние дела фреймворка. Аргументы на гитхабе что на yii пишутся сайты только "серьезные", пишутся командами, в которых есть админы, которые будут обслуживать эти ВПС-ы и дедики и подобное, просто убивают.
Почему то современные ЦМС-ы: бистрикс, джумла, друпал и т.д. в десятки раз нагруженней каркаса yii и почему то нормально живут на виртуальном хостинге. А те сайты, которые на них получаются..., такие чтобы по функционалу на yii найти, я думаю это еще очень поискать надо. Только вот эти ЦМС уже почти выбили веб программистов из сайтостроения вот таких средней (да и совсем даже не средней ;) ) сложности сайтов, т.к. их используют веб-мастера, а не программисты.
Посыл в том, что не забывайте про миллионы сайтов хостящихся на виртуальном хостинге, он всем удобен непосредственному заказчику, и эти сайты можно было бы собрать именно программисту на yii.
Ура, опомнились! Спасибо.
2Слава: Простые сайта на Yii чаще всего пишут только для себя. Большое отличие Yii от битрикса, Yii - не CMS и промышленной CMS на Yii нет. Именно поэтому нишу "простых" сайтов для клиента Yii и не занял и не займет, пока не будет промышленной известной CMS.
Да, сейчас Yii популярен и найти программистов на Yii становится все проще и проще, но, повторюсь, промышленной CMS нет, значит нет "стандарта", значит каждый сайт - велосипед и вот отсюда уже много побочных вещей вытекает.
Поэтому абсолютно согласен с аргументом, что на Yii пишутся только серьезные сайты с командой (ну или как написал выше - "для себя")
давно пора на 5.4 :) сам уже давно перешел, хоть и не использую все, что есть нового, но с точки зрения безопасности и задела на будущее - решение правильное!
plandem, что значит нет промышленной CMS на yii? У вас может и нет. А у других есть. Может не прям цмс, но наработки сравнимые с любой базовой ЦМС. Уточняю именно цмс, а не конструктора сайтов как джумла и друпал.
Та неохота искать, но я видел какую то платную цмс для магазина, написанную на yii. Из бесплатного да - нету.
Эти вещи уже просто не опенсоурс, а бизнес.
А на бюджет такой чтобы сложный сайт писать с нуля на yii , все полностью и с админкой, мало наших заказчиков поведутся. Нужно думать и о обычных сайтах.
Насчет сайтов для себя вообще смех. Вы кто разработчик или побаловаться? Что там кодер может пописать для себя кроме блога и баловства...
Очень бы хотелось со временем получить ответ о стабильности текущего api у yii2, чтобы наработки начать уже переносить.
Наработки - это есть велосипед. "Где-то видел, но лень искать" - это как раз и значит, что нет промышленной и известной цмс.
И если бы ко мне пришел исполнитель как вы и сказал бы, что у него есть свои супер наработки сравнимые с теми и теми и вообще он мега гуру, я бы его проводил до двери. Написать - одно, поддерживать - другое.
Про все остальное нет ни желание вступать в дискуссию, ни смысла что-то доносить. Вы слишком круты, а я так....пойду бложик поделаю.
Plandem, ну если у вас нет никаких наработок, которые есть "велосипед", то вы значит ничего не программировали в реальности и вообще не программист.
И мнение свое в теме о программировании вам оставлять не очень умно, т.к. звучит как дурня.
Сидите со своей джумлой, это ваш максимум, я же вам не мешаю, не мешайте и мне своим имхо.
:)) тяжело, наверное, после школы с такой-то манерой общения :)
Обратной совместимости с Yii 1.1 всё равно нету, так что даже если бы CMS или CMF была - её пришлось бы переписать целиком, от и до. Как и придётся переписывать/переделывать все свои наработки, поделки и.т.д.
А решается всё просто - будет репозиторий расширений, будут полу-официальные расширения, будет концентрироваться на них и писать патчи туда, а не клепать +100500 одинаковых расширений :)
Это правильно, отказываться от анонимных функций с полноценным $this - было бы серьёзной архитектурной ошибкой. Это дешёвая гибкость без 100500 абстракций и точек входа, у плясок с DI.
Psih, я о чем и говорю, мигрировать есть чего. Для этого нужен хотя бы стабильный апи.
Насчет общедоступных расширений согласен, но они начнут писаться тоже когда апи стабилизируется.
Но лично для себя, среди свободно доступных расширений под yii 1 (там их было время людям писать), я не особо много полезного нашел. То что мне нужно - придется писать самому. Так что я на ваш репозиторий под yii2 особо не рассчитываю, нет сигналов что он будет чем то круче того же что под yii 1.
Пока вы тут разглогольствуете об репозитории и стабильном апи, люди уже вовсю переписывают свои расширения.
Роман, ну там только три вкладки, так что про "вовсю" это не более как разглагольствование ;)
Насчет переписывают уже сейчас, так перепишут еще пару разков когда апи сменится.
Как выше заметили $this в анонимных функциях (как выше заметили) и трейты - это не шутка, можно для архитектуры ключевых вещей их заюзать. Ядро то yii2 потом не сменишь, а оно надолго.
Считаю что очень своевременно. Нет смысла ориентироваться на старое...
Отличная новость. Ждем альфа версии.
Ничего не ждём альфа-версии.
Работаем уже на девелоперской.
Живи быстро — умри молодым :-)
О, здорово. Сами написали пару проектов на 5.4, ощущения очень положительные. Синтаксический сахар очень нравится.
Умри молодым, оставь красивый труп. (c) Futurama
Эх, ещё б неймспесы с большой буквы... А так ждём-с, да.
Я бы это тоже поддержал... как-то красивее получается ) и не отрываться от коллектива)
Я тоже за CamelCase неймспейсы. Для меня стало неожиданностью увидеть в паблик превью Yii2 неймспейсы в нижнем регистре...
А когда планируется релиз Yii2?
Evgeny, пока чёткой даты нет. Я очень надеюсь на весну, но там уж как пойдёт...
Plandem цмс на yii я знаю несколько. Например yupe
Amarox, и насколько серьезно вы ее использовали? Скорее всего сейчас там уже лучше стало, но чуть меньше года назад все было очень сыро - побаловаться для себя, да, выбрать как решение на продакшн - увы нет.
Александр, подскажите, пожалуйста, не по теме.
Имеем AR модель, Post. Пользователи могут редактировать только модели, принадлежащие им, а модераторы - все модели. Также кол-во доступных к редактированию атрибутов у пользователей и модераторов разное. Предположим, у пользователей свой view, у администраторов - свой (возможно даже в разных модулях приложения). Как правильнее всего разделить логику правил модели?
Александр, подскажите, пожалуйста, не по теме.
Имеем AR модель, Post. Пользователи могут редактировать только модели, принадлежащие им, а модераторы - все модели. Также кол-во доступных к редактированию атрибутов у пользователей и модераторов разное. Предположим, у пользователей свой view, у администраторов - свой (возможно даже в разных модулях приложения). Как правильнее всего разделить логику правил модели?
2 Александр: а в чем проблема сделать на каждое поле свое rbac правило и в уже в роли юзеров накидать эти rbac правила - кому что разрешено.
а во вьюхах уже показывать только те поля, которые разрешены (тогда будет одна большая вьюха для всех)
это конечно не исключит варианта, если "хакер вручную отправил данные которые не разрешены" для этого юзера, но если нужно еще и валидацию завязать на rbac, то придется тогда один валидор сделать, который будет проверять атрибут на rbac правило.
Молодцы, что решились на 5.4!
Даешь CamelCase namespace!
+1 за CamelCase namespace! Больше претензий пока нет... Даже внешне выглядит как-то красивее, завершенее как бы. Кстати, а почему такое упорство разработчиков? Есть ли какие либо реальные аргументы или веские доводы?
Andy, да нет. Просто так больше нравится. А так и то и то соответствует PSR.
По-моему это перегиб. Полно полезных вещей написано.
2Gemorroj, салют) Если спросят, я в общем-то тоже за верхний регистр в неймспейсах. Чисто эстетически смотрится лучше.