FormModel does not work with Models that use KVO #31

Closed
seanlilmateus opened this Issue Aug 17, 2012 · 5 comments

Comments

Projects
None yet
2 participants
@seanlilmateus

The FormModel does not work if you use add an observer on the model class, example take the Formmodel example

in file #user_controller.rb

class UsersController < UITableViewController
viewDidLoad
    super
    self.title = "Scoreboard"
    self.users.first.addObserver(self, 
                      forKeyPath:'team', 
                          options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld, 
                          context:nil)
  end
...
...
  def observeValueForKeyPath(key_path, ofObject:obj, change:change, context:context)
    NSLog("Changed #{obj.class.ancestors}") 
    if key_path == "team" and obj.respond_to?(team)
      UIAlertView.alloc.initWithTitle(obj.name, message:"team: #{obj.team}", delegate:nil, cancelButtonTitle:"OK", otherButtonTitles:nil)
    else
      super
    end
  end

end

The UsersController fails to load the user's form_properties.

@clayallsopp

This comment has been minimized.

Show comment Hide comment
@clayallsopp

clayallsopp Aug 17, 2012

Owner

Interesting, this happens...

nsnotifying user

Owner

clayallsopp commented Aug 17, 2012

Interesting, this happens...

nsnotifying user

@clayallsopp

This comment has been minimized.

Show comment Hide comment
@clayallsopp

clayallsopp Aug 17, 2012

Owner

Ahhhh okay, the properties are getting lost when the subclass is created, since they're linked to just the User class:

(main)> c.users[1].class
=> NSKVONotifying_User
(main)> c.users[1].class.ancestors
=> [NSKVONotifying_User, User, Formotion::Formable, NSObject, Kernel]
(main)> c.users[1].class.form_properties
=> []
(main)> User.form_properties
=> [{:property=>:name, :row_type=>:string}, {:property=>:score, :row_type=>:number, :transform=>#<Proc:0x6e9f850 (lambda)>}, {:property=>:team, :row_type=>:picker, :items=>["Red", "Blue", "Green"]}]
Owner

clayallsopp commented Aug 17, 2012

Ahhhh okay, the properties are getting lost when the subclass is created, since they're linked to just the User class:

(main)> c.users[1].class
=> NSKVONotifying_User
(main)> c.users[1].class.ancestors
=> [NSKVONotifying_User, User, Formotion::Formable, NSObject, Kernel]
(main)> c.users[1].class.form_properties
=> []
(main)> User.form_properties
=> [{:property=>:name, :row_type=>:string}, {:property=>:score, :row_type=>:number, :transform=>#<Proc:0x6e9f850 (lambda)>}, {:property=>:team, :row_type=>:picker, :items=>["Red", "Blue", "Green"]}]
@seanlilmateus

This comment has been minimized.

Show comment Hide comment
@seanlilmateus

seanlilmateus Aug 17, 2012

usually when you observer an Object , it turns to NSKVONotifying_Object; this happens in Macruby too, but this NSKVONotifying_Object should still respond to all the same methods.

I believe the method #to_form should return a value, but when observing it, it return nil.
I'll check if it's an issue by includeding or / and __ extending__ objects

usually when you observer an Object , it turns to NSKVONotifying_Object; this happens in Macruby too, but this NSKVONotifying_Object should still respond to all the same methods.

I believe the method #to_form should return a value, but when observing it, it return nil.
I'll check if it's an issue by includeding or / and __ extending__ objects

@clayallsopp

This comment has been minimized.

Show comment Hide comment
@clayallsopp

clayallsopp Aug 17, 2012

Owner

This fixes it, seems to be the right way to do it:

805046c

Let me know your thoughts

Owner

clayallsopp commented Aug 17, 2012

This fixes it, seems to be the right way to do it:

805046c

Let me know your thoughts

@seanlilmateus

This comment has been minimized.

Show comment Hide comment
@seanlilmateus

seanlilmateus Aug 17, 2012

even though class variables are so harmful in Ruby, I think it's make sense to use it here :-)
there are associatedObject in Objective-C have to test if they work with Rubymotion. They could be an alternative solution.

even though class variables are so harmful in Ruby, I think it's make sense to use it here :-)
there are associatedObject in Objective-C have to test if they work with Rubymotion. They could be an alternative solution.

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