А, да, так у меня так и было)
Я спрашивал на счет того, чтобы перегружать доступные свойства классов, которые напрямую заданы, а не сложены в специальный хэш.
Решением стало, собственно, при инстанциировании перенести эти свойства в хэш и кильнуть.
Такой изворот, т.к. это бибилиотека для дочерних классов)
Но за пример в любом случае спасибо
egorinsk, типы данных, валидаторы, мапперы, отношения и ООП — вот этим я как раз сейчас и занимаюсь. И пока получается очень даже шустро и компактно (правда, переписываю уже третий раз, меняя интерфейс, но то такое). Адаптер и квери билдеры уже есть — я это делаю для Codeigniter, поверх ActiveRecord и DB Forge, которые там тоже очень неплохо реализованы и никаких нарекений по производительности пока не вызывали.
XML-конфигов у меня нет. Всё пляшет от объектов и их свойств. А результаты обработок свойств лёгенько кешируются в APC.
Конечно, вряд ли это будет супер-пупер универсально и на все случаи жизни, но 98% юзкейсов покрывать должно)
Дело в том, что нужно создавать объекты классов не только своих, но и чужих, которые написаны могут быть по-разному.
Спасибо за ссылку, кажется, то что надо
Мда уж, кажется, я переработался. Извиняюсь за беспокойство, но действительно ерунду упорол. Это, таки фильтр фреймворка был…
Но что главное — я когда-то уже с таким сталкивался и читал где-то про срезание, даже в доках каких-то… Но, видимо, со временем все в памяти перепуталось.
Не, ну точто доступ извне только через модульроутер — это понятно. Прямой вызов извне, имхо, это очень плохо. Банально опасно (а, кстати, в ключе Codeigniter, о котором речь — невозможно :) ).
И вот сильно подмывает переложить ограничения доступа именно на роутер…
ЗЫ
благодаря этому обсуждению класс для организации модулей в CI созрел и, по-моему, стал отлично юзабелен, так что спасибо) Еще обкатаю и покажу на хабре.
Вопрос с ограничениями доступа, все же, никак не могу утрясти — то-ли на уровне модулей, то-ли на уровне роутера. плюсы явно есть у обоих подходов…
1. и 3 (про представления):
— согласен практически полностью, кроме того, что наличие встроенных представлений усложняет код модуля. Эти представления лежат ведь себе в отдельной подпапке внутри папки модуля и на логику модуля не влияют. И взаимодейтсвие с представлением — не на уровне модуля, а на уровне класса, который отвечает за загрузку и выполнение методов модуля (modulerouter тобишь).
Т.е. у меня сейчас как: при вызове модуля ( $this->load->module(%modulename%) *это codeigniter-style, все через суперобъект проходит, а классы загружаются loader'ом* ) возвращается объект класса module, у которого есть вспомогательные методы и метод run, в который передется имя метода, параметры и (опционально) представление. Если представление небыло передано — возвращаются данные (json?), если было — то производится поиск представлений с названием %modulename%_%viewname% в папке модуля и в общей папке представлений приложения (у него более высокий приоритет) и сразу возвращается html. Мне кажется, это довольно жизнеспособный вариант…
ХОТЯ чем дальше думаю над этим всем, тем больше склоняюсь к вашему мнению, что наличие этих шаблонов довольно сомнительно…
2. Вот за объект с правами — огромное спасибо. Это шикарная идея. У меня какие-то схожие мысли просачивались, но как-то не сформировались.
3. При RPC / REST запросах — тут конечно без видов, только json/xml.
Вообще, огромное спасибо, вы очень помогаете прийти к «истине»
1. «главное что там нет разметки отвечающей за представления вида данных» — почему? О_о Ведь самый кайф модулей — это уомплектованные и легко переносимые «пакеты», у которых помимо всего прочего есть и свои views (которые, при необходимости, можно перекрыть, но «в комплекте» все равно есть стандартные)
2. Но ведь какие-то модули (в данном приложении) могут быть доступны гостям, какие-то юзерам (которые авторизируются ведь в приложении, а не http-авторизацией), какие-то вообще определенным группам юзеров. Получается, эти правила нужно учитывать на уровне самих модулей? Но тогда ухудшается переносимость, т.к. если у одного приложения политика доступов одна, у другого — другая, то прийдется и модули модифицировать — не комильфо…
3. Модет быть, но тем не менее, вопрос «как скорее всего будет удобнее» открытый)
2. Тогда это получается по большому счету автоматическая реализация REST API и modulerouter должен пускать к себе только разрешенные коннекты или только к публичным модулям?
