Consider an application using Core Data and OpenGL.
Normally a model object (MVC) has no knowledge of views or controllers
for good reasons.
but in this case it must draw itself.
No, it doesn't must do anything. Views draw themselves, model objects
are state, and controllers are intermediaries. Notifications and
delegation are common alternatives to binding model objects directly
into the UI.
What problem are you trying to solve by knowingly violating the MVC
design patterns ?
When the draw method is called
by the view or controller the appropriate OpenGL context is current.
So far so good. The problem however is with OpenGL resources needed to
support drawing.
When a model object is added to the managed object context, specific
OpenGL resources need to be created. When a model object is removed
from the managed object context, OpenGL resources need to be cleaned
up.
It sounds like you're trying to create a tight 1:1 binding between
your model objects and controller objects to avoid actually writing a
controller layer.
A seemingly straight forward solution would be to do the OpenGL
initialization and cleanup work in the awakeFromInsert,
awakeFromFetch, and didTurnIntoFault methods of NSManagedObject. The
problem is however, the OpenGL context is not current when these
methods are called. These methods are called by the Core Data
framework which has no knowledge of the OpenGL context.
What you're proposing is the equivalent of saying that because you
allocated an object, or freed an object, it should allocate and free
OpenGL resources. This is like NSObject -init and -dealloc calling
into OpenGL. It's even weirder than that here, because you're not
even talking about new objects being inserted or old objects being
deleted. You want to create OpenGL resources for whatever random
subset of objects that happens to be pulled into memory.
This is hard, because you're going in the wrong direction.
Put a stake in the ground, that your model objects will never ever
call directly into OpenGL. Adjust your design accordingly, and go
from there.
- Ben
Also, tying expensive resources to the lifespan of objects is
generally a bad pattern.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
