> Как я понимаю всяки franework'и не подойдут для наших проектов?
под визитки они как правило не нужны.
> Опять же они все большинство под SPA?
На многих SPA можно сделать, но вам ничего не мешает генерировать статику на форнте и делать обычные страницы с использованием тех же фреймворков
Dier_Sergio_Great
)) Вы выбрали одну из худших CMS с точки зрения программиста (хотя с точки зрения конечного пользователя она не так уж и плоха).
Мой вам совет: чем раньше откажетесь от CMS в пользу фреймворков - тем скорее вырастите.
Увы, качественных фреймворков единицы: symfony, silex, да и пожалуй все. Всякие популярные laravel/yii (я между прочим как в прошлом фан yii это говорю) за свои плюшки требуют очень высокую цену. Как правило, жертвуется безопасностью, читабельностью, тестируемостью и производительностью ради лаконичности.
Если вы не знаете, что хотите - тогда лучше вообще ничего не устанавливать.
Если же знаете требования к софту, но не знаете его названия - корпорация добра вам в помощь.
> они ж сразу скопычиваются от пятерки открытых сайтов
щито паделать десу. Подобные проблемы, увы будут только накапливаться с течением времени.
> и это причем даже в Паппи. я уж молчу о десятке-другом дистрибов...
Еще раз. Ваш браузер, по видимому, не поддерживается. Это не проблема линуксов, это ваш браузер не поддерживается. То, что Chrome/FF жрут ресурсы - вовсе не проблема линушных дистрибутивов, это Chrome/FF жрут ресурсы.
1. Нет, есть форма обратной связи: https://toster.ru/feedback
2. Опять же, вопрос к поддержке. Но это вполне норм, сайт не тестируется в не популярных браузерах. Переходите на FF/Chrome, иначе - терпите и пишите в службу поддержки, может и исправят))
Nc_Soft
> Всякие присваивания в циклах даже в документации пхп есть
Верно, есть, но примеры пишут для ясности понимания, а не для того, что бы их копипастили.
В куче учебной литературы встречаются переменные $a, $b, $c, но это вовсе не значит, что это правильно.
> Про эти select * тоже многие пишут типа нельзя делать, но это тупо неудобно, стоит добавить/удалить поле в бд потом бегай правь везде.
Все верно. Требования выше не связаны с удобством. Они связаны: с безопасностью, тестируемостью, поддерживаемостью, легкостью чтения.
> Если есть AR, то иде все свойства автокомплитит все равно.
Если они явно прописаны - да, если не прописаны - скорее нет, чем да.
> На счет джоинов решаемо select table.*
Да не вопрос, решаемо)) Вот только в следующий раз при правках этого кода другому программисту потребуется еще лезть в БД и перепроверять какие поля есть в каждой из таблиц. Это время.
> Про запросы в шаблонах и запрет AR - если человек идиот, он там и коннект откроет к бд без AR
Верно, и не пройдет code review, с ссылочкой на требования MVC
> И даже у phpstorm бывают затыки (на ларавеле так точно), сидеть выдрачивать каждую строчку ради его причуд никому не надо.
Вот тут вы очень ошибаетесь. Я не просто так по вбрасывал на счет хреновости laravel. Прочитайте мой ответ regretful. Проблема не в шторме.
Поймите, требования выше рассчитаны на крупные проекты, что бы минимизировать ошибки и экономить время команды на разработку. И вот это задрачивание как раз и решает эти проблемы.
Как пример: при использовании AR с магией как вы узнаете какие там есть поля и каких они php-шных типов? Лезете в БД и проверяете по коду, использующему эти поля (не обязательно в модели). Это спокойно может занять 5-15 минут у программиста не работавшего с этим кодом.
В случае использования явных определений: вводим $entity->set и смотрим автодополняшку, все типы уже будут указаны для каждого из полей. Для программиста, впервые работающего с этим entity это секунды!
Это неявная выборка. В случае изменеия структуры бд, например удаления колонки, вы узнаете об этом только в момент обработки, а не ранее на этапе запроса. Т.е. система уже не отвечает требованиям, заложенным ранее, а ошибка будет постфактум гдето дальше в коде.
В случае джойнов подобное вообщ нельзя писать от слова совсем так как будете иметь кашу из данных.
Рекомендую придерживаться принципа: явное лучше, чем не явное
