Что может быть примитивнее? Документ… его нельзя редактировать смертным… считай как посылать документы вордовские людям. Тоже список документов привязанных к пользователям. Намного более просто и в реализации и в использовании нежели извращения с форумами
Одна беда с этими фреймворками — безбожно тормозят. Мы как-то отделом взяли все доступные фреймворки и попытались реализовать на них простенькое приложение… На устройствах с процессором менее гигагерца наблюдалось тупение интерфейса. Для iPad скажем пошло хорошо, да и на топовых моделях тоже неплохо… Но всеравно катят они только для сверхпростых приложений.
Ответ тот же — Yii, покрайнемере на мой вкус это самая качественная реализация паттерна MVC (с довольно хорошим объяснением в русской доке) и неплохая архитектура в плане ООП. + знания технического английского для изучения кода и комментариев к нему необходимы довольно невысокого уровня, все самое сложное переведет гугл транслэйт (если конечно человек не критин и не способен из контекста понять суть). Таким способом подучить инглишь к слову намного более эффективно, как по мне, чем сначала учить оный а потом браться за фреймворк.
Удачи в поисках и в обучении «компании»)
Введение в Yii полностью переведено на русский, есть достаточно хороший русскоязычный портал а так же ветка на оффициальном форуме. Для более детального изучения уже надо лезать в доку по API и тут уже знания инглиша пригодятся.
ну так никто не заставляет использовать ВЕСЬ фреймворк. YII Достаточно гибок, в нем есть все необходимое для реализации API любой сложности, организовать фильтрацию данных и прочее тоже труда не составит. Так же порог вхождения достаточно низок. А так как вы не представили требований — то увы… Для своих целей у меня реализован класс для работы с REST SOAP сервисами. Единственное что иногда делаю — собираю в один файл только используемые классы. Так что такой подход мне видется достаточно нормальным, особенно в плане агрегатора или сервиса по синхронизации. Но это дело выбора.
Что тут подробнее… Берешь друпал, пытаешься сделать на нем сайт, и вуаля — ты уже знаком со частью недостатков этой системы. так можешь попробовать несколько CMS, записать список того что понравилось и главное — того что НЕ понравилось. А потом думать как сделать все что понравилось и исправить что НЕ понравилось. Думать придется долго ибо сложно уследить за всем.
P.s. А вообще я против универсальных CMS. Это слишком много говнокода. фреймворк и отдельные моули — куда ни шло…
Проблема была решена отключением dropа для всех контейнеров кроме того, что вызвал ивент over. Собственно в этом ивенте и было произведено действо. Других способов как я понял и не существует.
Dennion, ничего не мешает при переходе в продакшен все закэшировать по максимуму.
По поводу реализации КФС в Kohana… По сути своей она мне кажется удобной, но выбранный метод реализации кажется мне не самым удобным/эффективным… В любом случае интересно будет подумать над этой реализацией а именно предугадать когда КСФ эффективнее евентов… А то и вообще можно их комбинировать…
Последний вариант не рассматриваю так хотелось бы обойтись без жесткого регламента всех компонентов.
Модель с ивентами используется и в YII — и мне довольно нравится. Правда сторонники каскадной ФС постоянно ругали именно ту отрицательную черту этого подхода, что вы указали. Я вот думал как с этим бороться…
Хотя по сути не могу назвать это недостатком… модуль по своей сути не должен ничего знать о приложении… то-есть он должен знать ровно столько — сколько ему положено. Не могу пока представить ситуации, где бы это было критично. Если бы кто-либо предложил такую ситуацию — было бы очень неплохо.
