Jak przesłonić prezentację NSError w przypadku powiązań?

Question

Jedną rzeczą, z którą zawsze miałem problemy w wiązaniu kakao, była prezentacja błędu, na przykład gdy użytkownik wpisze błędną wartość do pola tekstowego z dołączonym formatatorem. Normalnie przesłoniłbym willPresentError: gdzieś w łańcuchu respondenta, ale moim problemem jest to, że obiekty NSError utworzone przez system Bindings nie zawierają wystarczającej ilości informacji, aby mi powiedzieć, co się nie udało, lub jeśli jest to nawet błąd, który mnie interesuje w dostosowywaniu. Mógłbym całkowicie usunąć wiązania z równania i stworzyć własne błędy, gdy pojawią się problemy z walidacją, ale czuję, że w ten sposób wyrzucę jakieś użyteczne rzeczy.

Udało mi się ominąć to poprzez wdrożenie metod delegatów NSControl i przechowywanie kontroli, która nie powiodła się w zmiennej instancji w moim kontrolerem widoku. Jeśli liczba ta nie zostanie zmniejszona do zera, gdy pojawi się willPresentError:, wiem, co nie udało się sprawdzić.

- (BOOL)control:(NSControl *)control didFailToFormatString:(NSString *)string errorDescription:(NSString *)error; 
{ 
    _errorSender = [control retain]; 
    return NO; 
} 

- (NSError *)willPresentError:(NSError *)error; 
{ 
    if (_errorSender != nil) 
    { 
     NSMutableDictionary *userInfo = [NSMutableDictionary dictionaryWithDictionary:[error userInfo]]; 
     NSString *help = NSLocalizedString(@"Why are you always messing up? You are a terrible person.", @""); 

     [_errorSender release]; 
     _errorSender = nil; 
     [userInfo setObject:help forKey:NSLocalizedRecoverySuggestionErrorKey]; 

     return [NSError errorWithDomain:[error domain] code:[error code] userInfo:userInfo]; 
    } 

    return [super willPresentError:error]; 
} 

To działa, gdy pierwsze zmiany responder, ale nie wtedy, gdy zadzwonię commitEditing na kontrolerze widoku, więc jest to tylko częściowo przydatne do mnie.

Jedyną inną opcją którą widzę jest wyjęcie NSFormatter z równania i użycie validateValue:forKey:error: w moich obiektach zarządzanych Core Data do obsługi sprawdzania poprawności. Nie ma to dla mnie większego sensu niż używanie formatera, ale przynajmniej miałbym pełną kontrolę nad obiektem NSError.

Czuję, że muszę czegoś przegapić, aby uzyskać taki rodzaj rozłączenia z obsługą błędów. Jakieś sugestie?

Answer 1

I could completely remove bindings from the equation and create my own errors when validation problems occur, but I feel like I would be throwing out some useful stuff that way.

Można użyć NSUnderlyingErrorKey owinąć jeden błąd (obiekt dla tego klucza) w innym błędem (ten, którego userInfo że zawiera klucz).

The only other option I can see is taking NSFormatter out of the equation, and using validateValue:forKey:error: in my Core Data managed objects to handle validation. This doesn't make as much sense to me as using a formatter, but at least I'd have full control over the NSError object.

Są to dwa osobne poziomy i nie wykluczają się wzajemnie. Walidacja formatowania odbywa się w warstwie widoku; walidacja klucz-wartość (w tym przypadku w zarządzanych obiektach) znajduje się w warstwie modelu.

Jeśli dana walidacja ma się odbyć w warstwie widoku, podklasuj klasę NSFormatter (jeśli jeszcze tego nie zrobiłeś) i wprowadź getObjectValue:forString:errorDescription:, aby zwrócić bardziej szczegółowy opis błędu. (Nie mam pojęcia, czy Wiązania rzeczywiście wykorzystuje ten opis błędu, choć. Należy sprawdzić).

Jeśli walidacja powinna nastąpić w warstwie modelu wdrożenia validate<Key>:error: (w wersji single-własność validateValue:forKey:error:) w podklasie NSManagedObject.

Jeśli niektóre wiązania znajdują się w warstwie modelu, a inne w warstwie widoku, wykonaj oba. Możesz zaimplementować niektóre kontrole w formatyzatorze i inne kontrole w modelu, jeśli ma to sens w przypadku Twojej aplikacji i czeków.