Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid UserInfo accessors generated. #158

Closed
batkuip opened this issue Apr 24, 2013 · 5 comments
Closed

Invalid UserInfo accessors generated. #158

batkuip opened this issue Apr 24, 2013 · 5 comments
Milestone

Comments

@batkuip
Copy link
Contributor

batkuip commented Apr 24, 2013

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.

@batkuip
Copy link
Contributor Author

batkuip commented Apr 25, 2013

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?

@rentzsch
Copy link
Owner

  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.

@rentzsch
Copy link
Owner

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

@batkuip
Copy link
Contributor Author

batkuip commented Aug 12, 2013

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants