Wie kann ich die NSError-Präsentation überschreiben, wenn Bindungen involviert sind?

Question

Eine Sache, mit der ich in Cocoa Bindings schon immer Probleme hatte, war die Fehlerdarstellung, zum Beispiel wenn der Benutzer den falschen Wert in ein Textfeld mit angehängtem Formatierer eintippt. Normalerweise würde ich willPresentError: irgendwo in der Responder-Kette außer Kraft setzen, aber mein Problem ist die NSError Objekte durch die Bindungen System erstellt nicht genügend Informationen enthalten, für mich zu sagen, was fehlgeschlagen ist, oder ob es auch ein Fehler, den ich im Customizing interessiert bin. Ich könnte Bindungen vollständig aus der Gleichung entfernen und meine eigenen Fehler erzeugen, wenn Validierungsprobleme auftreten, aber ich habe das Gefühl, dass ich auf diese Weise einige nützliche Dinge rausschmeißen würde.

Ich habe in der Lage, dies zu umgehen, indem sie die NSControl Delegatmethoden Implementierung und Speicherung die Steuerung, die in einer Instanzvariablen in meiner Sicht Controller ausgefallen. Wenn es bis zum Zeitpunkt willPresentError: nicht nil ist, weiß ich, was nicht validiert wurde.

- (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]; 
} 

Dies funktioniert, wenn die Ersthelfer Veränderungen, aber nicht, wenn ich commitEditing auf den View-Controller nennen, so ist es mir nur teilweise nützlich.

Die einzige andere Option, die ich sehen kann, ist NSFormatter aus der Gleichung zu nehmen und validateValue:forKey:error: in meine Core Data verwalteten Objekte zu verwenden, um die Validierung zu behandeln. Dies ist für mich nicht so sinnvoll wie die Verwendung eines Formatierungsprogramms, aber zumindest hätte ich die volle Kontrolle über das NSError-Objekt.

Ich fühle mich wie ich es etwas zu sein, diese Art von disconnect mit Fehlerbehandlung fehlen werden müssen. Irgendwelche Vorschläge?

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.

NSUnderlyingErrorKey Sie können einen Fehler (das Objekt für diesen Schlüssel) in einem anderen Fehler umwickeln (die eine, deren userInfo enthält, die Taste).

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.

Dies sind zwei separate Ebenen, die sich nicht gegenseitig ausschließen. Die Validierung des Formatierungsprogramms erfolgt auf der Ansichtsebene. Die Schlüsselwertüberprüfung (in diesem Fall in Ihren verwalteten Objekten) erfolgt auf der Modellschicht.

Wenn die fragliche Validierung auf dem Ansichtslayer stattfinden sollte, unterklassieren Sie Ihre NSFormatter-Klasse (falls nicht bereits) und implementieren Sie getObjectValue:forString:errorDescription:, um eine spezifischere Fehlerbeschreibung zurückzugeben. (Ich habe keine Ahnung, ob Bindungen tatsächlich verwenden diese Fehlerbeschreibung, though. Sie überprüfen sollen.)

Wenn die Validierung auf der Modellschicht passieren sollte, implementieren validate<Key>:error: (die Single-Eigenschaft Version von validateValue:forKey:error:) in Ihrer NSManagedObject Unterklasse.

Wenn einige der Einschränkungen bei der Modellschicht sind und andere sind in der View-Ebene, beides tun. Es steht Ihnen frei, einige Überprüfungen im Formatierungsprogramm und andere Überprüfungen im Modell durchzuführen, wenn dies für Ihre App und Ihre Überprüfungen sinnvoll ist.