Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Ничего особенного собственно и нет, по такому же принципу можно создать отдельный репозиторий с Yii2 и постепенно клонировать с переписыванием в него модели, контроллеры и т.д.
Это да, но сам репозитарий в данном контексте ничего не меняет. Он может быть, как отдельным, так и «все в кучу». Я скорее описываю свою методику: выполнять миграцию не «глобально» — «все старое на все новое», а пошагово.
Про «ничего особенного» согласен.
Просто части видел ситуации, когда берется именно глобальная задача и люди в ней увязают, либо от миграции вообще отказываются ибо «страшно».
Про «ничего особенного» согласен.
Просто части видел ситуации, когда берется именно глобальная задача и люди в ней увязают, либо от миграции вообще отказываются ибо «страшно».
Т.е. даже когда стоит задача переписать полнофункциональный «модуль», в котором, например, 5 контроллеров, 10 моделей и которые тянут за собой еще туеву кучу зависимостей то да — это сложновато и иногда страшно (или лениво).
Если же рассматривать задачу в контекте «переписать страницу».
А это всего один action и «пара моделей», а нужные связанные модели реализуются, например, только в рамках маппинга на БД, то всё выглядит значительно проще и делается быстрее.
Если же рассматривать задачу в контекте «переписать страницу».
А это всего один action и «пара моделей», а нужные связанные модели реализуются, например, только в рамках маппинга на БД, то всё выглядит значительно проще и делается быстрее.
Когда переводил проект с symfony1
на Symfony 2+, то на уровне nginx сделал прямое перечисление старых роутов на старые фронтконтроллеры, а по дефолту на новый. Всегда было легко определить сколько ещё переписывать. Да и уменьшение долга было визуально заметно, что мотивировало. А необходимость менять конфиги сервера для добавления роута в легаси мотивировала делать в новой.
Тоже размышлял про nginx, но решил, что мне будет лень регулярно лазить в его конфиг. Т.к. пошел по противоположному пути, не по «дефолту на новый», а только роутинг нового пока не накопится достаточный объем.
>по дефолту на новый
А сколько лет было проекту?
Просто в своем я не рискнул перечислить все старые роуты, боясь что-нибудь потерять. А чужой был мне недостаточно знаком для этого.
>по дефолту на новый
А сколько лет было проекту?
Просто в своем я не рискнул перечислить все старые роуты, боясь что-нибудь потерять. А чужой был мне недостаточно знаком для этого.
Если проекты на yii, продолжают развиваться, то каждому разработчику рано или поздно приходит мысль: «как было бы хорошо, если бы это было не Yii»
Или даже «не PHP».
Yii отличный инструмент для прототипирования и быстрого создания сайтов.
Сейчас больше всего мешает привязанность к jQuery и слабое разделение фронтенда и бэкенда.
В прочем, версия 3.0 обещает это если не исправить на 100%, то хотя бы улучшить.
Но это уже будет совсем другая история.
Yii отличный инструмент для прототипирования и быстрого создания сайтов.
Сейчас больше всего мешает привязанность к jQuery и слабое разделение фронтенда и бэкенда.
В прочем, версия 3.0 обещает это если не исправить на 100%, то хотя бы улучшить.
Но это уже будет совсем другая история.
В 2018 мигрировать на yii2 для сколько-нибудь серьезного приложения странно, минимум на yii3.
А так выглядит, что люди, которые умеют пользоваться только молотком, на все смотрят как на гвозди.
А так выглядит, что люди, которые умеют пользоваться только молотком, на все смотрят как на гвозди.
слабое разделение фронтенда и бэкенда
Хм… не замечал неудобств. Что имеется ввиду, если чуть конкретнее?
Если не замечали, то просто не было необходимости. На самом деле, я тоже с этим мало сталкивался. Но если вам нужен сайт не на JQuery, а при использовании Yii2 будет навязывать его почти что по умолчанию — приходится делать немало дополнительных манипуляций, чтобы выключить. У него есть модуль-сборщик JS и CSS в один файл и динамическая подгрузка нужных asset-библиотек, но при этом используются свои решения, а не как в том же Lavarel, где это сделано продуманнее с использованием стандартных инструментов типа Webpack (поправьте, если ошибаюсь).
Это все мелочи. Если ваш сайт завязан на JQuery — все хорошо. PJAX с коробки тоже позволяет вытворять ТАКИЕ динамические сайты, что мало не покажется — очень удобная возможность, особенно учитывая, что поддержка модуля идет почти что с коробки. Но если вы используете Angular/React, то вам придется потратить дополнительное время, чтобы перенастроить Yii2 под них.
Yii3 должен решить эти проблемы, но пока есть как есть. Нужно понимать, что делает Yii2 и зачем, и тогда вы «не выстрелите себе в ногу».
Это все мелочи. Если ваш сайт завязан на JQuery — все хорошо. PJAX с коробки тоже позволяет вытворять ТАКИЕ динамические сайты, что мало не покажется — очень удобная возможность, особенно учитывая, что поддержка модуля идет почти что с коробки. Но если вы используете Angular/React, то вам придется потратить дополнительное время, чтобы перенастроить Yii2 под них.
Yii3 должен решить эти проблемы, но пока есть как есть. Нужно понимать, что делает Yii2 и зачем, и тогда вы «не выстрелите себе в ногу».
Про Jquery согласен, есть такое. Я имел ввиду коммент по слабое разделение front/back. Или имеется ввиду, что и там и там торчат уши jquery?
Я не ставил целью избавится от jquery полностью. В этом плане, да — необходимости не было. Но ужа с ежом скрещивал, например, webpack и vuejs применял на yii.
>Нужно понимать, что делает Yii2
Спору нет, но перефразировал бы: «Нужно понимать что делаешь» :)
Я не ставил целью избавится от jquery полностью. В этом плане, да — необходимости не было. Но ужа с ежом скрещивал, например, webpack и vuejs применял на yii.
>Нужно понимать, что делает Yii2
Спору нет, но перефразировал бы: «Нужно понимать что делаешь» :)
Да, «уши jQuery» относятся к этому. Еще критикуют виджеты, которые на себя иногда перетягивают бизнес-логику в неправильных руках (но с ними хотя бы проще: не нужно — не используй).
Yii из коробки предлагает много функционала, который жалко не использовать (activeForm) но при этом это PHP-код, причем объемный, и в итоге view-файлы имеют больше серверного кода, чем клиентского. Можно конечно отказаться от ActiveForm, ListView, GridView и т.д. — но они действительно упрощают многие вещи, но загрязняют фронтенд. Хотя в то же время можно использовать расширения-шаблонизаторы. В любом случае — никто не обязывает делать фронтенд именно таким, но так как он такой из коробки, и он такой в документациях и гайдах — все делают так, в итоге многие фронтенд-программисты плюются от этого, несмотря на то, что можно делать иначе.
Сейчас мы придем к тому, что front/front-у рознь и все зависит от продукта. Там где не «корпоративное использование», не back-офис, а front для обычных пользователей я стараюсь готовые вообще виджеты не применять (кроме activeForm) по тем же причинам.
ИМХО, все они — явный backend и на frontend я их видеть не хочу.
ИМХО, все они — явный backend и на frontend я их видеть не хочу.
>если бы это было не Yii
:) Оценил
Извините, не холиварю.
:) Оценил
Извините, не холиварю.
Не стоит начинать миграцию, если у проекта нет ясного будущего в прогнозе на 2-3 года вперед. Либо вы делайте это для fun-а.
Очень важный пункт т.к. встречаются личности которым переписать или внедрить, что-то новое приоритет всех их жизни.
Хорошее руководство к действию. Потом также будем мигрировать с yii2 на yii3
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция проекта с yii1 на yii2 через единовременную работу