Конечно можно, но опять же — просто по тезисам это не слишком показательно. Как по мне выбор фреймворка должен исходить все же из задачи. Скажем, можно поставить 2-3 задачи, использующие плюсы сравниваемых фреймворков. Например с чем-то в реализации коханна будет эффективнее, а в чем-то YII. Исходя из этого можно уже составить представление для чего больше подходит тот или иной фреймворк.
В любом случае — мне было бы интересно участвовать в написании подобной статьи :)
Ну собственно если уж статья будет писаться — то было бы неплохо опубликовать хотя-бы топик-ссылку в блоге коханы. Было бы любопытно почитать.
что касается каскадной файловой системы — у нее много плюсов, это один из пунктов который можно было бы рассмотреть чуть подробнее и сравнить, скажем, реализацию модульности с другими популярными фреймворками. Хотя возможно и это уже сделали.
Latin идет как исполнитель. Тут скорее под исполнителем просто говорится, что исполняется латино-американская музыка. Самого исполнителя найти сложно. Просто дайте послушать вашему другу сборники такой музыки.
то что нету аргументов? Ну так это в изначальное условие и входило. Однако это не мешает перегружать оператор и перенаправлять запрос на другой объект. (возможно выразился неточно...). Проблема в этом случае только одна — в моей реализации данные, которые должны быть приняты или выданы через оператор -> находятся, к примеру, в массиве. Решение которое я нашел по большей части решает эту проблему.
По сути все изменения которые необходимо сделать для более мение стабильной работы фреймворка можно сделать просто перегрузкой 2-х или 3-х функций в классе YII, который по умолчанию пуст и является наследником YiiBase. Остальные классы, если не вдаваться в вопрос оптимизации нагрузки, в изменениях не нуждаются. Касательно кеширующего слоя — у YII и так мощная система кеширования, а в новой версии появился таковой в компоненте CActiveRecord — что довольно ощутимо снижает прожорливость. В любом случае надо экспериментировать.
YII достаточно гибкая система что бы реализовать на ее основе любой функционал. Конечно большая масштабируемость увеличивает затраты ресурсов. Но отказываться от CActiveRecord или CUrlManager я бы не хотел — слишком мощьные инструменты. Остается лишь вариант переписать базовые классы. Или же портировать эти компоненты под свой фреймворк (благо лицензия позволяет использовать фреймворк или его компоненты в любых целях).
Собственно вопрос состоял в том, что думают программисты при работе с такими «монстрами» — что бы они хотели видеть, какую структуру и какие плюшки облегчающие жизнь. Пока я видел лишь пару вариантов идеальных для разработки но они жрут много ресурсов (чем-то приходится жерствовать). Конечно спасает кеширование, но иногда бесит отсутствие золотой середины между удобством и производительностью. Как вариант написать что-то типа «предкомпиляции» узких мест — когда то что пишется на уровне API системы склеивается и упрощается для уменьшения количества абстракций.
В таком случае вы должны предоставлять возможность посмотреть исходник лишь для потенциального заказчика. Тобиш в вашем портфолио будет разделение на то, что можно смотреть, и что нельзя без предварительного разрешения вами. Конечно полностью это не обезопасит, но хоть немного спокойнее будет.
Со всем согласен но не могли бы вы остановиться на втором пункте чуточку поподробнее? Допустим CMS основана на фреймворке. Согласен, размер дистрибутива (если его предварительно не уменьшили) может достигать тех же значений что и остальные CMS. Но как по мне это не сильно большая проблема при более менее грамотной системе подключения файлов (допустим YII).
А вот вопрос о «толстом ООП» и MVC меня немного смутил… Нелегко разобраться в конкретной реализации или в целом? Как-то паттер MVC призван все же более упростить разработку. Да и для меня разобраться с хорошо написанными приложениями было намного легче. Можете пояснить?
В любом случае — мне было бы интересно участвовать в написании подобной статьи :)