Do you do something similar with the DB connection? I've now got a model in my framework and a model in my application. Some of the entities in the framework are generic and can optionally be subclassed (User); others are unlikely to be subclassed (UserLogEntry).
How do I tell the framework that its entities should be accessed via the connection in the model in my application rather than the one in the framework's own model?
As Chuck suggested there is already many implementation to do it. But yes most of them (if not all of them) will do it listening to this exact same notification, get the model, get the connection dictionary and play with it.
Just to be consistent with all your other models, I would suggest to use the same mecanism for all models, so use an already proven method (see Chuck's message).
Add this special implementation for this special case of model munging.
And if a method in the framework fetches and returns an entity, how would it know to return the subclass of the entity defined in the application rather than the generic entity in the framework? (This question probably shows my confusion... I'm sure I'm just thinking about this problem wrong!)
Think about it like :
I need to modify the model to make it coherent and consistent, maybe change more than only one model.
But I can't change the serialized version (the .eomodeld result of EntityModeler), so I need to change the exact same EOModel graph of objects but once they just get loaded in memory.
To help you identify what need to change, I suggest :
- Save a backup copy of all of your unaltered eomodeld files.
- Modify your models so that they work for your project, fix the relationships across models, the attributes, etc. save them.
- diff your backup and your fixed models, the changes you see are the one you will have to make at runtime, in that notification.
- jfv
On Jul 16, 2008, at 5:09 PM, Jean-François Veillette wrote:
Whenever used, we use the notification of model loaded, and at runtime change whatever values needed to be tweeked for the current project. Like changing table name, setting isAbstract (or not), playing with relationship, etc.
Here is a simple case where we define the isAbstract attribute on all the entities of a generic model :
first ...
NSNotificationCenter.defaultCenter().addObserver(AProjectControlerClass.class, new NSSelector("modelLoadedNotification", new Class[] { NSNotification.class }), EOModelGroup.ModelAddedNotification, null);
and latter ...
public static void modelLoadedNotification(final NSNotification notification) {
NSLog.debug.appendln(AProjectControlerClass.class.getName() + " notificationModelCharge...");
EOModel model = (EOModel) notification.object();
if (model.name().equals("AGenericModel")) {
NSArray entities = model.entities();
log.info(model);
Enumeration enim = entities.objectEnumerator();
while (enim.hasMoreElements()) {
EOEntity entity = (EOEntity) enim.nextElement();
log.info(entity);
entity.setIsAbstractEntity(true);
}
}
}
- jfv
Le 08-07-16 à 17:32, Chris Meyer a écrit :
And what about adding additional relationships specific to the application to the User entity?
Name it GenericUser (or whatever) in the framework. Subclass GenericUser as User in the app model and add whatever you need. Done.
Great! It sounds like I'm on the right track.
So how does WO handle the table name? In the framework, the GenericUser entity will have a table name (and, implicitly, a DB connection). When subclassing/extending the object in the _application_, is the table name and connection in the _framework_ just ignored?