Всем привет, почувствовал на собственной шкуре, либо я чего-то не знаю либо это крайне проблемное место Yii.
Собственно о чем это я…
Сохранение связанных данных. Я балдею от механизма relations это все очень круто избавляет от написания больших джоинов и т.д. имеет красивый вид… НО это никак не помогает делать запись!
Т.е. к примеру где-то на русском сайте есть пример про то как сохранять связанные данные. Я бы хотел что бы кто-то из профи этого фреймворка смог мне ответить на несколько вопросов:
Во-первых, рассмотрим ту же ситуацию что и в кукбуке надо сохранить к примеру комманду и к примеру 10 ее членов
Хорошо ли делать так как в кукбуке ? при сохранении 10ти ее членов будет сделано 10ть инсертов ??
Второе, как быть с валидацией в случае если имя игрока не проходит валидацию? Надо бы не дать сохранить имя комманды если имя игрока не проходит валидацию, ну тут я думаю должны помочь транзакции… и все же как Вы подобные вопросы решаете…
Ну и самое интересное надо же ведь иметь возможность не только создать такую вот комманду но и редактировать, причем надо иметь возможность редактировать одномоментно и название команды и всех ее игроков…
Задача кстати крайне распостраненная.
Я думаю большинство вопросов было бы снято если б фреймворк пользовался своими же relatuibs’ами и для сохранения а не только для чтения.
Извините, а с каким фреймворком вы работали что он это дело облегчал или выполнял сам?
Я б тоже с ИИ хотел познакомится… А вобще идея нормальная, может кто выделит время на подобное расширение. Хотя если тебя не устраивают 10 инсертов то думаю лучше смотреть в сторону DAO а не AR
Ну молодцы - спасибо Вам… пришли поржали, поумничали…
Я конечно понимаю что реализовав это вероятно большую часть работы он будет брать на себя - согласен, но по мойму для этого и создавались фреймворки и все как ни крути к этому идет ?
Я в принципе не про ИИ говорил а про то что если это не реализовано в фреймворке, то как это решают профи ?
Я про, к примеру, форму редактировани связанныъ данных …
или про валидацию …
Как сохранять написали, но то что написали ведь это чистой воды поделка.
Ладно фиг с ним с этим большим количеством инсертов, меня больше интересуют вопросы чуть выше…
Я бы просто делал интерфейс, где на одной странице отображаются данные о команде в общем и о каждом игроке. На яваскрипте написал бы возможность добавления/удаления новых игроков. А внизу страницы большую кнопку "Сохранить".
В обрабатывающем экшене сделал бы валидацию такую какую надо и сохранение.
Все, на самом деле ничего сложного. Делал подобное уже пару раз в разных проектах. Реализация занимает максимум 3-4 часа.
p.s. И не использовал бы никакие relations при сохранении. Там и связывать то практически нечего.
Далеко не всегда мы участвуем в проектах в которых мы же являемся и проектировщиками и дизайнерами и юзабилити специалистами и т.д… бывает так, и у взрослых дядек очень часто, что нужно выполнить ту задачу которую перед тобой ставят и выполнить именно так как ее уже утвердили и решили, особенно когда эта задача решаема.
Интересно боольшая кнопка сохранить отличается чем то от маленькой ? что это ??
отличный ответ сделал бы валидацию такую как надо… супер! Лучше ж ничего не написать правда ?
конечно сложного вообще ничего нигде нет … так всегда говорят люди которые … ладно не буду продолжать.
Только подумайте если бы можно было бы в месте с атрибутами массово присвоить и связанные данные а фреймворк бы уже сам все распихал бы по полочкам … что тоже бы не использовали бы ?
Какая нахрен полезность вашего ответа ?? Если мы на форуме где все как бы помогают друг другу … то в чем ваша помощь в этом ответе ? Типа я крутой программер и сделал бы все это раз плюнуть ?? ну так мой ответ в самом первом слове. читайте его чаще что бы раньше юношеский максимализм проходил.
Т.к. форум служит для популяризации фреймворка задумайтесь сколько людей новичков и нет изучая этот фреймворк пытаются решить схожую задачу ??
Это кстати огромная проблема данного фреймворка отсутствие жизненных примеров в кукбуках и особенно в апи… нету примеров … наверное форум для этого и создавался что бы восполнить недостатки … ?
В общих словах стуктура такова. Три таблицы/модели:
список проектов
тексты на разных (в данном случае на двух) языках для проектов (многое-к-одному)
изображения для проектов (многое-к-одному)
Код специфический и не решает твою задачу полностью, но дает ясный намек и ясность как делать. Надеюсь в коде разберешься.
p.s. За "минус" к посту #5 остался неприятный осадок. После такого в разы уменьшается желание помогать. Я не прошу "плюсов", но и "минуса" я не заслужил.
А я и не требовал. Если внимательно прочесть мой первый пост то я как раз спрашивал … уж простите если не наколнях стоял при этом …
Что по коду то я не хочу его комментировать дабы не вызывать лишние споры.
Скажу лишь что мне не понравилось то что и как сделано, хотя говорить об этом наверное неверно так как до конца (в деталях) задача твоя мне не известна. Поэтому без комментариев.
Скажу лишь что пока обсуждали тут все я потихонечку все решил самостоятельно.
Могу сказать что сделал совсем иначе.
в контроллере в котором происходит сохранение связанных данных я всего лишь имею строчку типа
$model->save()
а все остальные манипуляции я провожу в моделе.
в методе beforeValidate я заполняю сво-во модели в котором будут содержаться связанные данные, тут же и определяется что эти данным идут на сохранение или на обновление
в методе rules добавляю правило которое проверяет эти связанные данные
а в методе afterSave эти связанные данные сохраняю, потому как этим связанным данным нужно присвоить значение внешнего ключа а оно будет у нас на руках только после сохранения.
Не включая транзакции я убиваю нескольких зайцев, и самый главный из них это - пока не пройдет валидация всех данных никто в БД не попадет и это гуд!.
Во-вторых, как по мне приятнее иметь логичный контроллер и использовать на максимум возможности фреймворка.
Ну а в третьих остается только в виде проверять есть ли ошибки валидации и выводить их.
Мне кажется на эту тему стоило бы написать кукбук… а может уже и не стоило бы
Я в самом начале что на этом сайте я нашел кукбук на эту тему но он не раскрыт полностью.
Т.е. не раскрыты вопросы валидации, ничего в кукбуке не сказано о редактировании и т.д. это не кукбук а фуфло, плюс к тому он не лишен недостатков и в начале темы я все их описал… а ты тут пришел и просто тупо увеличел ссылочность на твой сайт красавец! -1
как и многие кстати кукбуки тут и там … они не "живые".
Это не проблема, пишите соответствующий Behavior, который будет шерстить relations() на предмет объектов с свойством isNewRecord и делать массовое сохранение. Так же может заниматься оптимизацией операции ‘INSERT’, чтобы делать всего 1 запрос. Это довольно практично, но могут быть ситуации, когда требуется дополнительная обработка. Шаблонный код в контроллере, готовый для дополнительных обработок:
$team=new Team;
$valid=true;
if(isset($_POST['Team'],$_POST['Member']) && is_array($_POST['Member']))
{
$team->attributes=$_POST['Team'];
$valid=$team->validate();
foreach($_POST['Member'] as $key=>$member)
{
$members[$key]->attributes=$member;
$valid=$members[$key]->validate() && $valid;
}
if($valid)
{
//Если нужна транзакция, то тут можно объявить её начало
$team->save(false);
foreach($members as $member)
{
$member->teamID=$team->id;
$member->save(false);
}
//Если была начата транзакция, то тут объявляем её конец
}
}
Если это используется таким образом, то в шаблонах сохраняется возможность использовать все CHtml::active*() методы, даже не взирая на то, что $_POST[‘Member’] массив. В том числе сохраняется возможность выводить ошибки валидации всех моделей через CHtml::errorSummary(), либо общую ошибку по состоянию флага $valid.
$team=new Team;
//Можно создать нужное кол-во объектов members тут.
$valid=true;
В том месте где я указал комментарий, можно создать нужное кол-во объектов members, для того чтобы иметь возможность передать их в виды, что в свою очередь позволяет использовать CHtml::active* методы и пользоваться CHtml::errorSummary() для вывода ошибок и $team и $members. Или есть вариант делать 1 общую ошибку для всех members по состоянию флага $valid.