Посоны просят, я не против. Я тебе говорил, что кое-кто провокатор. Но их оказалось больше. Мне кажется здешний контингент приуныл в общей массе и стал более чем надо циничен и дерзок. Да и сам портал/форум утопает потихоньку. Не удивительно, но за державу обидно. Такой домен, просите, проёбывать просто святотатство.
Правильно коллеги говорят - "всё зависит от задачи". Если говорить о сферическом коне, то (R): Где-то когда-то писал (не дословно): - для мелкого проекта (сайта-визитки, например) использовать CMS - для среднего проекта - фреймворк - для крупного - чистый PHP (или другой) Это для "бизнеса". Если "ради своего удовольствия как разраба", то лучше всего чистый PHP, в крайнем случае ФВ. Стоит помнить, что "фреймворк" это просто библиотека готовых решений, не более. Коллеги, говорившие выше, правы - если у Вас "большой проект" (т.е. крупный проект), то со временем у Вас появится/создастся свой ФВ. Будет он лучше или хуже уже готовых ФМ, зависит только от Вас и/или вашей команды. По этому поводу коллеги, говорившие выше, и правы и неправы одновременно. Правы в том, что любое универсальное решение будет медленнее, чем узкоспециализированное. И не совсем правы, например, говоря что "Скорость исполнения это не фетиш ... Гораздо важнее сосредоточиться на цели, не отвлекаясь на детали.". Тут опять всё зависит от задачи. Например, если задача сделать проект, который генерит 1 млн страниц в сутки на сервер с пиковой нагрузкой 2млн (*2), то пофиг сколько времени генерится страница - 0.1с с использованием ФМ или 0.01с на чистом ПХП. А если задача - 10млн, то ФМ уже зло. Аналогично с временем разработки - чтобы создать свой ФМ понадобится несколько месяцев, чтобы изучить - пару недель. Выбирать что важнее по задаче. И т.п. И по поводу "проще менять разрабов, когда они все знают фреймворк" тоже "и правы и неправы". Правы в том, что проще найти "юного падавана", который уже изучил универсальный ФВ и неправы в том, что на "большой проект" надо брать этих юниоров. А хорошему разрабу пофиг на чём писать - переход с ПХП на ФМ или с ФВ на ФВ займёт всего пару недель, или меньше. Как-то так...
+ 100500 И свои 5 копеек Когда пишется что то новое и уникальное, всегда в любом ФВ упираешься в то, что стандартное работает "немного не так как нужно". И тут встает дилема "допила" стандартного под свои нужды Как правило это решается правкой кода ФВ. А потом в ФВ находится дырка, его обновляют и пистец...все поплыло ВСЕ имхо конечно же ) Вобщем пиши на чистом.
Это никогда не делается. Не знаю, как Laravel, но Yii2 позволяет любой стандартный компонент подменить на свой благодаря dependency injection. Kohana, которой пользовался до этого, позволяет сделать то же самое благодаря архитектуре HMVС. То, что в папке vendor - свято, и не меняется.
В итоге, в оригинальной ветке дырку заделали, а ты, из соображений "трону, сломается", остаешься с дыркой в поправленном коде.
однажды мне тоже пришлось делать правки в ядре одной цмс(кажись Expression Engine), ибо заявленный в документации функционал работала некорректно в некоторых граничных(как раз наших) случаях. проект был долгий. и к моменту выхода в продакшн, версию цмс меняли несколько раз из за всяких добавленных плюшек. В итоге мне пришлось при каждом обновлении цмс, повторно опять править и ядро. Благо сам код ядра менялся мало, и костыль мой оставался практически неизменным.
Ну так свой стараешься наследовать от стандартного, и поправить только то, что нужно тебе. Так что есть надежда, что поправка сработает. В принципе, по поводу дыры оба варианта - и поправить vendor, и использовать DI - одинаково мороки может доставить.
Ведешь свои фиксы в ветке куда мержишь пришедшие изменения ядра цмс. Если мало менял - вообще без проблем, даже не заметишь.
ну да. так проще мержить, до тех пор пока там не появятся изменения которые полностью обесценят код костыля или проблема не уйдет в другое место. все равно нужно каждый раз анализировать изменения и смотреть на что теперь костыль повлияет, и не сломает ли он вообще логику работы. ну и в идеале конечно нужно еще автоматизированное тестирование, чтоб видеть что ничего не сломалось от костыля.