Потому что codeigniter умер при родах. Symfony существует не первый год, это один из самых популярных фрейморков. В него и его экосистему не так давно инвестировали что-то около 8 миллионов евро. Это решение enterprise уровня, да и тенденции к отчищению самого языка от скверны то же есть.
Проблема PHP в другом, отсутствие у большинства культуры разработки. По этому большая часть разработчиков на PHP и дешевле. Но если брать сильных разработчиков, будет одинаково по стоимости что PHP что Ruby.
@DubecZ это кажется геморным только первое время. Скажем я уже не представляю себе жизнь без всего этого. Еще вам пригодился бы опыт поддержки сайта. Мол написали вы что-то в этом стиле, а через пол года заказчик просит вас допилить чего... и вы хватаетесь за голову ибо не помните как оно все работает, изменения делаются крайне долго, появляются регрессии функционала... правда пожалуй это лучше прочувствовать поработав сначала с проектом с нормальной архитектурой.
@ARezvanov да, REST API это сервер. То есть вместо выплевывания шматков HTML он будет возвращать только данные и обрабатывать запросы приложения на клиенте. Читать про архитектуру клиент-сервер.
1) начнем с автозагрузки классов. Почему бы ее не использовать? Есть стандарты, PSR-0/PSR-4 которые описывают как что должно работать и т.д. Есть готовые автозагрузчики, можно воспользоваться composer, можно для PSR-0 сделать свой в несколько строк и больше никогда не страдать этой фигней с require_once/require.
2) у вас класс Core почему-то наследуется от класса Settings, что как бы не логично. Логично было бы класс Settings передавать в конструктор Core. Да даже если и оставить все как есть, почему в файле содержащем Core-класс нету подключения с файлом класса сеттингов? оно там как бы нужнее. И мы опять же возвращаемся к вопросу автозагрузки классов, с ней было бы симпатичнее уже
3) делать коннект к базе в конструкторе дурная идея. Вообще делать что-то кроме инициализации ДАННЫХ в конструкторе дурная затея. Самый простой случай, мы создали инстанс, он подключился к базе, но нам и не нужно было лесть в базу и в итоге у нас довольно много времени сьело подключение в никому не нужной базе данных. Ленивое подключение намного лучше в этом плане
4) Есть такая штука как принцип единой ответственности. По нему, класс должен уметь делать только что-то одно. Если у вас один и тот же класс отвечает за работу с базой и логированием, уже что-то пошло не так. Согласно этому принципу, у нас должна быть только одна причина поменять что-то в реализации класса. А тут у нас их две - переделать работу с базой и обработка логов
Намного лучше в этом ключе сделать отдельно класс для работы с BD и класс для логирования и передавать их в конструктор класса
5) почему бы раутинг так же не вынести в компонент какой? Было бы удобнее. А еще лучше - воспользоваться готовым компонентом, хотя я надеюсь что этот код вы пишите исключительно в образовательных целях и в продакшен он никогда не попадет. Если это так, то тогда свой велосипед можно и нужно писать, но следует выносить все это дело в отдельный компонент, который будет ресолвить какой контроллер дергать.
6) Если вы выполнили все пункты выше, у вас может возникнуть мысль что как-то не удобно работать с такой кучей разных классов. И тут вы будете правы, посему придумали такие штуки как контейнеры зависимостей, сервис-локаторы и т.д. Эти штуки проистекают опять же из принципа единой ответственности и инверсии зависимостей. У вас должен быть компонент, который умеет собирать другие компоненты и только это он и будет делать. Вы у него просите $container->get('db') а оно либо создаете вам инстанс класса DB либо выдает ранее созданный. Причем регистрацию всех этих штук можно вынести в файл и там делать как-то так:
$container->setParam('db.hostname', 'localhost'); // можно значения из файла подтягивать
....
$container->define('db', function ($container) {
return new DB($container->getParam('db.hostname'), ...);
}
фух... Если вам кажется что все это лишний оверхэд, то да. Может так показаться. Но следует приучать себя делать все именно так что бы потом при увеличении сложности проектов не писать говнокод.
@0neS сомневаюсь. В наше время HTML58 ассоциируется с интерактивными приложеньками и прочими радостями современной жизни.
@ARezvanov это в идеальном случае. Все зависит от кучи факторов. Если это просто web-приложение, то да. Если там что-то должно индексироваться поисковиками - уже будете веселее. Словом краткий ответ - смешивать можно, если осторожно. Чем менее связаны они будут - тем лучше.
@AMar4enko не вижу противоречий, jCrop это только составляющая, чисто контрол (как по мне). Я свой контрол для кропа намучался делать пару недель назад (специфичный слишком), а так прикрутил и радуйся.
А то что на английском, google translate, да и по коду там ясно что как делать.
@nokla возьмите за основу тот же хромиум, целее будете. Вы представляете себе масштаб работы? Одному человеку за вменяемое количество времени не реализовать даже просто webview. Только если брать готовое, что пилится уже не один год.
С тор сетями не знаком, подсказать не смогу. Но исходники открыты как бы.
@ArturAralin у вас есть ресолвы для раута, которые гарантируют что пока не отработает промис ничего не произойдет. Вариантов сделать это все масса. Суть в том что вы не раскрыли никаких подробностей. Что в json, где используется и т.д.
Из чистого любопытства... Раскройте контекст вопроса. Просто по вопросу кажется что вы говорите о реализации некой прослойки для работы с файлами. В тоже время можно включить read ahead в файловой системе (для некоторых точнее)... я не слишком сведущ в этой теме, посему позволил себе полюбопытствовать.
Проблема PHP в другом, отсутствие у большинства культуры разработки. По этому большая часть разработчиков на PHP и дешевле. Но если брать сильных разработчиков, будет одинаково по стоимости что PHP что Ruby.