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?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
