adding observers

[naoyamakino]

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]

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]

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

[jonathanpenn]

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]

@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.