Invalid UserInfo accessors generated.

[Thomas van der Heijden]

Pull request #131 to create accessor for UserInfo is very handy. However it doesn't clean the UserInfo keys and can cause compilation failures esp on existing data models. For instance, my model is full of "com.apple.syncservices.Syncable" UserInfo keys which generate invalid objective-c code.

[Thomas van der Heijden]

I've been looking into this some more and it looks like it needs a slightly different kind of solution. The problem is that userInfo's can contain anything, keys and values. Just parsing out the dots/whitespace is not going to cut it. Also it's assumed that the userInfo is static while it's not. You can change userInfo at runtime.

I do see this functionality being useful though. What about prefixing? That way you can set some rules. There is already a "mogenerator.readonly" key, so what about anything that starts with "mogenerator."? Value has to be a string.

Thoughts?

[Wolf Rentzsch]

1. Yeah, for user info keys we have to be careful. I say skip over any that seem troublesome. Practically that means any key that contains non-alphanumeric characters. We have to be a little stricter than +[NSCharacterSet alphanumericCharacterSet] though, since that lets in the troublesome periods. Here's what I came up with, it's basically [a-Z0-9_] in regex syntax:

   NSMutableCharacterSet *validCharacters = [[[NSCharacterSet letterCharacterSet] mutableCopy] autorelease];
   [validCharacters formUnionWithCharacterSet:[NSCharacterSet decimalDigitCharacterSet]];
   [validCharacters addCharactersInString:@"_"];
   NSCharacterSet *invalidCharacters = [validCharacters invertedSet];
   NSString *input = @"uno_Dos";
   NSRange r = [input rangeOfCharacterFromSet:invalidCharacters];
   NSLog(r.location == NSNotFound ? @"PASS" : @"FAIL");
   

2. For the values, the only thing I think we need to be concerned about is escaping C-string quotation marks.

3. I'm fine with user info being static for efficiency reasons. Folks can use MyEntityAttributes.myAttributeName as a key and use the standard Core Data APIs to extract that info at runtime. With the exception of +insertInManagedObjectContext:, mogenerator doesn't generate Core Data helper code. That's out of its scope.

4. mogenerator's user info key namespace is currently all over the map. I'll probably have to go in and take a survey later and create a new coherent naming system. But now's not the time.

[Wolf Rentzsch]

Punting this to 1.29. No forward motion in a while and I don't want to hold up 1.28.

[Thomas van der Heijden]

Does this mean you are taking the pull request out? Current master branch is unusable for me because of this. Just generates bad code.

[amroelsherif]

Hello.....So What we can do to support non-alphanumeric characters like dots