Как мне переопределить представление NSError, когда задействованы привязки? - PullRequest
Новая
       6

Как мне переопределить представление NSError, когда задействованы привязки?

7 голосов
/ 23 мая 2009

Одна вещь, с которой у меня всегда были проблемы с привязками Какао, - это представление ошибок, например, когда пользователь вводит неправильное значение в текстовое поле с присоединенным форматером. Обычно я бы переопределил willPresentError: где-нибудь в цепочке респондента, но моя проблема в том, что объекты NSError, созданные системой привязок, не содержат достаточно информации, чтобы я мог сказать, что не удалось, или если это даже ошибка, я заинтересован в настройке , Я мог бы полностью удалить привязки из уравнения и создать свои собственные ошибки, когда возникают проблемы с проверкой, но я чувствую, что я бы выбрасывал некоторые полезные вещи таким образом.

Мне удалось обойти это, реализовав методы делегата NSControl и сохранив элемент управления, который потерпел неудачу, в переменной экземпляра в моем контроллере представления. Если к моменту проката willPresentError: значение не равно нулю, я знаю, что не удалось проверить. 

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

Это работает, когда меняется первый респондент, но не когда я вызываю commitEditing на контроллере представления, так что это только частично полезно для меня.

Единственный другой вариант, который я вижу, - это исключить NSFormatter из уравнения и использовать validateValue:forKey:error: в моих управляемых объектах Core Data для обработки проверки. Для меня это не имеет такого большого смысла, как использование средства форматирования, но, по крайней мере, я имею полный контроль над объектом NSError.

Мне кажется, что я что-то упустил, чтобы не было такого рода разъединения с обработкой ошибок. Есть предложения?

1 Ответ

4 голосов
/ 23 мая 2009

Я мог бы полностью удалить привязки из уравнения и создавать свои собственные ошибки при возникновении проблем с проверкой, но я чувствую, что я бы выбрасывал некоторые полезные вещи таким образом.

Вы можете использовать NSUnderlyingErrorKey, чтобы обернуть одну ошибку (объект для этого ключа) в другую ошибку (ту, в которой userInfo содержит этот ключ).

Единственный другой вариант, который я вижу, - это исключить NSFormatter из уравнения и использовать validateValue: forKey: error: в моих управляемых объектах Core Data для обработки проверки. Для меня это не имеет такого большого смысла, как использование средства форматирования, но, по крайней мере, у меня будет полный контроль над объектом NSError.

Это два отдельных уровня, и они не являются взаимоисключающими. Проверка правильности форматирования выполняется на уровне представления; проверка значения ключа (в данном случае в управляемых объектах) выполняется на уровне модели.

Если рассматриваемая проверка должна произойти на уровне представления, создайте подкласс класса NSFormatter (если вы этого еще не сделали) и реализуйте getObjectValue:forString:errorDescription:, чтобы получить более конкретное описание ошибки. (Я не знаю, действительно ли Bindings использует это описание ошибки. Вы должны проверить.)

Если проверка должна происходить на уровне модели, внедрите validate<Key>:error: (версия с одним свойством validateValue:forKey:error:) в вашем подклассе NSManagedObject.

Если некоторые из ограничений находятся на уровне модели, а другие на уровне представления, выполните оба действия. Вы можете свободно выполнять некоторые проверки в форматере и другие проверки в модели, если это имеет смысл для вашего приложения и ваших проверок.

...