Возможно сама операция сканирования нагрузочная, но не более 1 сек при большом наборе файлов, а обычно 50-100 млсек, но когда данные берутся из кеша, то на это тратится около 0.3 млсекунды, если не меньше.
Все же я иду больше от того, что PHP array это файлы исходного кода, а не файлы конфигурации. Пусть даже это и приводит к небольшому ухудшению производительности.
На счет кеша байткода, я так и предполагал, однако например APC мне не давал в этом смысле какого-то выигрыша. Возможно Zend Opcache ведет себя по-другому.
Assets которых нет в репозитарии можно держать в папке проекта и подключать их напрямую, используя относительный путь в шаблоне. Я точно не уверен, но кажется в Symfony просто указывается папка с assets. В Regenix если вы подключаете bootstrap, с ним автоматически тянется и jQuery, той версии, которая с ним совместима. Далее, когда вы подключаете bootstrap в шаблоне, подключать jQuery не нужно (т.к. это его зависимость), он подключается автоматически.
Да я это понимаю (вначале так и было), сделал ради оптимизации. Возможно в будущем просто напишу утилиту, которая будет собирать из исходников один файл.
htaccess прописан так, что прямого доступа к файлам нет, только к статичным. Фреймворк можно держать в отдельной папке, он подключается откуда угодно, главное подключить файл include. Но пока я над этим сильно не работал.
Там хранятся зависимости от assets библиотек — javascript, html, css библиотеки. Еще там хранятся зависимости к модулям фреймворка, но это еще под вопросом, возможно они будут хранится в composer.
PHP не поддерживает классы внутри классов. Иногда это было бы полезно. Фреймворк позволяет объявлять несколько классов в одном файле, однако частично соблюдается стандарт PSR-0 (проверку анализатором можно отключить) — название первого класса в файле должно совпадать с названием файла.
Есть два режима работы приложения DEV и PROD, в первом режиме (который включен по-умолчанию) почти ничего не кешируется таким образом. В режиме продакшена парсинг кешируется, вызываются лишь функции проверяющие время модифицирования файла, парсинг JSON и других конфигураций при каждом запросе не происходит если вы в продакшен режиме.
Чтение JSON не происходит каждый заново, конкретно deps.json и остальные файлы конфигурации кешируются в APC или XCache и перезагружаются только при изменении этих файлов. В фреймворке я старался снизить количество операций по чтению файлов. На счет хранения конфигураций в PHP файлах, исходил из того, что PHP файлы не для конфигураций и при желании новичок может засунуть туда какую-нибудь логику.
P.S. Я не отрицаю что фреймворк мудренный внутри, но код приложений достаточно простой и понятный.
Да все верно, нужно изменить, чтобы не вводить в заблуждение. На раннем этапе я исходил из того, что методы с буквой s на конце возвращают множественное значение и намеренно сделал эту ошибку.
На счет кеша байткода, я так и предполагал, однако например APC мне не давал в этом смысле какого-то выигрыша. Возможно Zend Opcache ведет себя по-другому.
htaccess прописан так, что прямого доступа к файлам нет, только к статичным. Фреймворк можно держать в отдельной папке, он подключается откуда угодно, главное подключить файл include. Но пока я над этим сильно не работал.
P.S. Я не отрицаю что фреймворк мудренный внутри, но код приложений достаточно простой и понятный.
* /api/{method} Api.action{method}
И будут вам методы view, list и new и методы надо будет именовать как actionNew, actionList и т.д.