Спасибо за ответ. Но задача заключалась именно в хранении в YML редактировании в YML без взаимодействия с БД. Решено было использовать тип поля SET, создать кастомный тип в Doctrine и связать все через менеджер (сервис). Как-то так.
Сергей Протько: задам уж тут вопрос, так быстрее, создал я тип поля и столкнулся с тем, что в тип-то ничего не заинжектить, а данные о категориях у меня хранятся в контейнере. Как быть ? Неужто не получится ограничится только типом поля и придется фигачить гидратор ? Я глянул ObjectHydrator так чуть не помер от количества всего в нем.
Сергей Протько: глянул. Получается вместо аннотаций, вида "ManyToMany(JoinTable()) и т.д." Просто создать свой тип поля, который будет хранить в себе массив значений ?
Сергей Протько: у меня тут еще вопрос, как система должна реагировать, на случай удаления значение (entity) из yml файла ? При удалении из БД все связи тоже подчищаются, однако же, при удалении из YML все же останется на месте. Я так понимаю, при выборке должна будет идти проверка на соответствие связи - действительности, и если сущность из YML уже не существует, удалять связь ? При использовании ManyToMany будем использовать свою коллекцию, т.е. нужно ее передавать при загрузке приложения в доктрину, чтобы она могла с ней работать ? И по поводу "еще один тип" - тип поля ? Может у вас там где ссылка завалялась на раздел из доков доктрины, как раз для этого случая ? А то ну совсем не понятно, что и в каком порядке нужно делать, каким образом доктрина будет знать, откуда брать данные для связи ManyToMany. Придется править аннотации ?
Сергей Протько: я вроде понял, а вроде и не понял. Ну вот есть у меня 50 записей. Я их закидываю в YML файл:
categories:
category:
id: 1
name: category_1
category:
id: 2
name: category_2
...
- это тупость и не вижу преимущества хранения в YML
или
categories:
category_1:
id: 1
category_2:
id: 3
...
- это тоже идиотия
или
categories:
category_1
category_2
...
- ну, а тут как тогда связывать с сущностями в БД ? ManyToMany например. По ключу массива ? Ну так, а если я поменяю местами значения ? Или хранить в виде:
categories:
FIRST_CATEGORY: category_1
SECOND_CATEGORY: category_2
...
- а если таких 50 значений ? Для каждого писать конский ключ ?
Это не к вам претензии, вы не подумайте, просто у меня бомбит от ситуации.
Сергей Протько: Про гидраторы я понял, сам процесс связывания осознал, только как организовать хранение связующей информации, использовать для этого сериализованные данные в ячейке таблицы, либо ключи массива из yml кидать в связующую таблицу , или ID для каждого элемента из YML списка прописывать вручную ?
Спасибо за ответ. Печаль-беда. Я-то надеялся на категорическое - "нет" )) Вопрос еще один - каким образов осуществлять связь между, например категорией и сущностью (например Image). Т.е. когда все хранится в БД, то есть таблица, например - image_categories, где два поля image_id и category_id. Тут же как организовать, если в yml будет написана только иерархия. Прописывать ID вручную, или использовать вместо ID - ключ массива ? Или вообще хранить категории в сериализованном виде ? Просто мой мозг говорит ,что это в высшей степени извращение и отказывается понимать всю ситуацию )
Вы уже справились ? Если нет то напишите это в блоке script после подключения библиотеки ангуляра. Дальше пропишите в body атрибутом ng-app="myModule".
Значит сперва валидировать всю пачку, в случае отказа - кидать исключение, в случае прохода валидации - сохранять. Просто приходится работать с большим объемом объектов на фронте (angularJS), после изменений вся пачка отправляется на сервер. До этого была очередь из объектов (взял объект -> отправил -> получил положительный ответ -> взял следующий объект и т.д.), но показалось не очень.
Tab Size : 4
Indent : 4
Continuation Indent : 8
--
Реакции ноль, к сожалению. Не реагирует ни на какую смену отступов вообще. Для PHP тоже не реагирует. Где еще могут быть какие-нибудь настройки ?
Спасибо ! Я неправильно вопрос сформулировал, да и затупил изрядно, искал-то я на самом деле плагин для добавления кастомных полей к терминам, просто вопрос не так сформулировал , а потом вспомнил про ACS )) Бывает тупняк иногда нападет.
Сергей Гаврилов: Это один из вариантов передачи. Так же я для себя спрашиваю, а не для других программистов, ну и в довершение - написание велосипедов, это один из замечательных способов познания предметной области.
