Yii Framework

Здравствуйте!
Есть 2 идеи, по расширению ядра.

1. Внести поддержку сущностей.
Есть базовая таблица с сущностями, есть таблицы "наследники", пример структуры DB:

Entity -- Базовая таблица, содержит поля: id, owner, type, _temp, create_time, update_time
Поле type, хранит в себе названия сущностей("User", "Post", и.т.д )
Entity_User
Entity_News
Entity_Post

Таблицы "наследники", имеют ID такой же как и базовой таблицы.
В конфигах DB, появляется параметр baseEntityTable.
Данная фича уже создана, и опробованна, на одном моем стартапе.

2. Для связываемой модели, добавить возможность передавать параметры.
1. Это поможет, в тех случаях, когда приходиться подстраивать Yii под существующие архитектуры.
2. Сделает работу с моделями более гибкой.

Возникает вопрос: будут ли такие фичи, если я их сделаю, приняты в ядро фреймворка?

Возникает вопрос: будут ли такие фичи, если я их сделаю, приняты в ядро фреймворка?

ИМХО. В ядро это не примут, т.к. это уже слой логики вашего приложения.

Не могли бы вы расписать, какие плюсы вашего подхода?

К фреймворку это отношения не имеет. Это больше подход к решению ряда проблем.

По 1 пункту,
я предполагал создать 2 отдельных класса CEntity(CActiveRecord) И CActiveEntity(CEntity),
Серьезные приложения основываются на подобных сущьностях, и если они будут в "коробке", это - здорово.

По пункту 2,
Разве расширение механизма реляции в ORM не относится к фреймворку? о_О

Ну так, делать или нет?
P.S. Ни хочеться делать форк, и отрываться от основного потока.

а я чтото не понял, о каких проблемах вы говорите? и чем данные "сущности" ее решают ):

Похоже, пример непонятный. Я не понял, зачем это нужно в фреймворке...

Пункт 1.
Это способ расширить фреймвок, с целью поддержания модели при которой ВСЕ данные в системе имеют общее начало, по аналогии с Drupal нодами. Прямо из коробки.

Пункт 2.
Передавать параметры в связываемые модели, как мне кажется, весьма интересная штука, можно разнообразить арсенал программиста.

P.S. Ну да ладно, проехали. Пусть, все остается как есть.

1. http://rmcreative.ru/blog/post/nasledov ... tsey-v-yii ?
2. Про это опять не понял...

2. getRelated наверно имеется ввиду, но это скорее касательно HAS_ONE, но опять же, как то не логично - настраивать модели ("передавать параметры" - я так понял конфигурировать)

А, так тоже можно при использовании lazy loading...

По пункту 2.

Есть 4 таблицы:
object, news, product, event

А также 4 таблицы, в которых хранятся локализованные значения:
translate_object, translate_news, translate_product, translate_event

Вопрос: Как используя всего ОДНУ модель, сделать универсальный подход для работы с 4 таблицами переводов, не используя eval ?
Именно через relations().
Спасибо!

А зачем это нужно?

1. Что бы интернационализировать существующий проект. В котором около 20 сущностей.
При этом плодить 20 однитипных файлов не хочется, у которых только разные названия.
2. Можно создавать связанные гибкие ДИНАМИЧЕСКИЕ модели(на лету). Включая фантазию, это мощьный инструмент в инструментарии программера.
3. Это даст конкурентное приемущество, перед всякими Симфони.

ээ, я шас юзаю уникальный экшен, который принимает type, возможные варианты - поиск, добавление, редактирование, детали, удаление, он универсален в примитивной работе, что касается модели и ее релейшенов, я пишу админку за часы, просто конфигурирую контроллер, нет ни экшенов (везде 1 универ) нет ни вььюх(везде 1 универ) есть абстракция, на мой взгляд она очень нужна, давайте встроим в фреймворк?