NSOutlineView, NSTreeController и гетерогенная иерархия
Это скорее комментарий, чем хороший ответ: (я бы предпочел добавить комментарий к одному из ответов выше, но у меня нет ответа)
Вопрос, как я его читал, «Я могу закрыть поток в сокете, а затем открыть поток в том же сокете?» ... но люди, кажется, отвечают на это: «Как я должен чисто закрыть мой сокет?» ... это не вопрос
Ответ на заданный вопрос - «нет». Когда вы закрываете поток, вы закрываете сокет.
(я понимаю, почему, по крайней мере в одном случае, кто-то может задать этот вопрос. Когда вы передаете Java-свойства через сокет, принимающая сторона должна см. EOF для распознавания конца свойств - чтобы получатель увидел EOF, отправитель должен закрыть поток / сокет. НО, если у вас есть протокол команд / ответов, работающий над этим сокетом, вы НЕ хотите его закрывать или вы потеряете канал, на который хотите отправить ответ. См. Свойства потоковой передачи Java поверх Socket для одного способа обработки этого сообщения)
2 ответа
Проблема, которую я вижу здесь, заключается в том, что при установке свойства "children" запускается KVO для " проекты "собственности, обратное не верно. Таким образом, если вы добавляете проект к объекту библиотеки через отношение «проекты», представление структуры не будет обновляться, потому что оно не увидит никаких изменений в свойстве «дочерние элементы».
Самый простой способ включить это - реализовать такой метод:
+ (NSSet*)keyPathsForValuesAffectingChildren
{
return [NSSet setWithObject:@"projects"];
}
При этом любые изменения в свойстве «projects» также должны вызывать уведомление KVO для «детей».
Кстати, поскольку свойство «children» не является частью вашей модели Core Data, я не думаю, что вызовы will / didAccessValueForKey: строго необходимы, хотя я не думаю, они что-нибудь повредят. Кроме того, если вы реализуете метод, упомянутый выше, вам больше не нужно будет вызывать will / didChangeValueForKey: в методе setChildren: , поскольку Какао должно автоматически запускать KVO для этого, когда ключ "проекты" изменен.
Я не думаю, что текущая версия NSTreeController требует атрибутов с именами "дети" и "родитель". Вы можете использовать setChildrenKeyPath:, чтобы установить путь к дочернему атрибуту на любое имя атрибута (при условии, что атрибут реализует иерархию родитель-ребенок). Я уверен, что это довольно старое требование. (Примите это с долей соли, я не использовал контроллер дерева некоторое время. См. ниже)
Что касается других ваших вопросов:
(1) Да
(2) Да, да и да
(3) Отношения поддерживаются в истинных атрибутах, например, в свойствах. Граф сущности/объекта отделен от виртуального графа, который виртуализируют свойства родителя и ребенка. Поскольку родительские и дочерние атрибуты на самом деле не имеют значений, любое изменение реальных значений немедленно отражается в их возврате и наоборот. Короче говоря, вам не нужно о них беспокоиться.
(4) Да, контроллер дерева будет наблюдать за виртуальными свойствами, а не за реальными. Если виртуальные свойства не соответствуют KVO, контроллер не будет работать.
(5) Исторически NSTreeController считался глючным. Он существует с IIRC 2004 года и никогда не работал хорошо. Многие старые специалисты просто игнорируют его. Я не использовал его уже некоторое время.
(6) Обычно вы кэшируете только те данные, которые, как ожидается, не будут сильно изменяться. Если выборка используется для фактического обновления модели или ожидается, что что-то еще обновит модель, например, запрос URL, то кэш не следует использовать.