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

adding observers #14

Open
naoyamakino opened this issue Dec 20, 2012 · 4 comments
Open

adding observers #14

naoyamakino opened this issue Dec 20, 2012 · 4 comments

Comments

@naoyamakino
Copy link
Contributor

hi Alloy, I am trying to add an observer-like behaviour in MotionData's managedObject.
here are few attempts I made
naoyamakino@6bc7050
this works expect what I want to do eventually is something like

Class Author < MotionData::ManagedObject
  afterSave :after_save
  def after_save(notification)
    #do something with notification
  end
end

here is my attempt
naoyamakino@9253454

this spec is failing and Author.after_save is not getting called.
I can't quite figure out why it is not calling it and how to make it work.

one thing I notice is that self in naoyamakino@6bc7050#L0R57 is an instance of RecipeListTableViewController but here naoyamakino@9253454#L1R130 is Author class itself.

first of all, do you think my approach to add observer behaviour is a right track?
and do you have any suggestions on how to make it work?

thanks for your time.
cheers

@alloy
Copy link
Owner

alloy commented Dec 20, 2012

I’ll have to think about it when I have a bit more time (hopefully tonight), but it would really help if you could tell me your use case for it.

@naoyamakino
Copy link
Contributor Author

@alloy say after save to context, might want to sync back to server etc.

@jonathanpenn
Copy link
Collaborator

It might be better to put the observer on the context, then. I can imagine this getting complicated, though. The reason observers work with ActiveRecord in Rails is because there is one data store and a "save" means that the data is persisted.

In Core Data, a "save" means that you're committing the changes in that managed object context. It's possible, if you have a child object, that you're not persisting to disk, yet, until the parent object context saves. I think that adding observers like this to the models themselves can be real problematic. Do you want those observers called when "save" is called on any context? Or only on persistence? That's what make me think this is a context level concern and not a model level concern.

On Dec 20, 2012, at 11:28 AM, Naoya Makino [email protected] wrote:

@alloy say after save to context, might want to sync back to server etc.


Reply to this email directly or view it on GitHub.

@alloy
Copy link
Owner

alloy commented Dec 21, 2012

@naoyamakino I’m also unsure about what approach to take, so maybe it’s better if you first workout the best solution locally in your app and then once satisfied work on extracting it to a more abstract solution.

Btw, the context that saves to disk is Context.root, so you might want to use that one to be notified of.

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

No branches or pull requests

3 participants