Workaround, moving the constraints into code

[kcergfalo]

Hi, it's me, the Olaf from Stackoverflow.

You are raising an interesting point there:

The workaround works fine when you're starting a new project. But users of the framework who are already using Core Data probably have constraints specified in the model and adding my framework would mean moving all of that to the validation method.

A sightly different way would be to read the model and to extract the validation constraints. If the model does not contain any limits, i.e. the user of the framework did not set any limits, then the framework can set limits for the entity. Either limits are will be validated agains the attribute.

Basically what the code should be doing is to override validateValue:forKey:error:. It obtains the limits from the validationPredicates in the model. If no validationPredicates are defined in the model then the entity has its own validationPredicates defined in code.

The validationPredicates are applied to the value. If there is a validation mismatch then an error is generated. A bit of cosmetics is merging the attribute name (key) and the limit value expectedLimit into the error message <key> can't be more than <expectedLimit>

There is no change to the view.

I have hacked something together to demonstrate above. I will try to add a pull request., something I have never done here before, so please be patent with me.

[murraysagal]

Hi Olaf,

Thanks for thinking about this. It's an interesting idea. The approach achieves the goal but the cost is pretty high: reimplementing Core Data's validation engine.

For me it's too high a price. It would be an incredible amount of work to get it right in all cases. And conceptually I struggle to get my head around it. Specifically, there's nothing wrong with Core Data's validation engine. The problem is what it does after it validates (providing a pretty much useless error message). So, for me, completely rewriting something really big that's not actually broken so I can hook into the process is a tough call.

I think instead it might be better for me to put some effort into convincing Apple to implement suggestion 1 which would eliminate the problem altogether.

Anyway, let me know if you think I'm misunderstanding your approach.

Murray =:-)

[kcergfalo]

Hi Murray,

No, you didn't misunderstand my approach. Please see it a nice little Friday after lunch hack to check out some concepts. And I do agree with you on the effort needed, suggestion 1 is definitely something to go after. When you raise a radar then please let me know the reference. I will back you up.

Still, I am still thinking on how I could move parts of the hack into my current projects. A custom validation method fetching the limits from the model is very interesting because it would add consistency.

Let's assume a project with most of the attributes using no or only standard validation but with a few attributes that need a custom validation. With the min/max limits all defined in the model administering would become easier. It would let the programmer focus on setting limits while eliminating the risk of creating conflicts between hardcoded limits in a custom validate method and limits set in the model.

My idea goes in the direction of an category on NSManagedObject to get the limits from the model. I will see what can I put together.

• Olaf