Hey Larry, You could try adding a subclass of ERXFrameworkPrincipal to your model framework. It will get loaded even before the Application constructor so I think you could do all your model swizzeling there.
From ERXExtensions.java (in, shockingly, ERXExtensions): /** * Principal class of the ERExtensions framework. This class * will be loaded at runtime when the ERExtensions bundle is * loaded (even before the Application constructor is called) * This class has a boat-load of stuff in it that will hopefully * be finding better homes in the future. This class serves as * the initialization point of this framework, look in the static * initializer to see all the stuff that is initially setup when * this class is loaded. This class also has a boat load of * string, array and EOF utilities as well as the factory methods * for creating editing contexts with the default delegates set. */ public class ERXExtensions extends ERXFrameworkPrincipal { Good luck! Dave On Feb 24, 2014, at 12:31 PM, Laurence Mills-Gahl <elem...@gmail.com> wrote: > Aaron, > > I think that per-model properties should work well in this case so you don’t > need to put connection dictionary information in the model itself. > > On the topic of automatic loading during launch, I also am separating model > groups for using separate OSCs and wonder if there is a better way to deal > with this than what I’m doing now. > > I would like to keep models in standard location (Resources) so it’s easier > to deal with when I forget why I moved them out of the way in the first > place. > > At the moment, I’m removing models from the default group in the application > constructor and creating the other groups I need there. I’m uncomfortable > with this design because it feels like the model groups should be managed in > the model framework and not the application project… although that gets a bit > tortured also. > > Any thoughts? > > > Larry Mills-Gahl > elem...@gmail.com > > > > > > > On Feb 24, 2014, at 10:54 AM, Aaron Rosenzweig <aa...@chatnbike.com> wrote: > >> Hi David, >> >> Try just putting that connection info directly into EntityModeler and stop >> using the global properties. I know it is convenient to use a separate >> properties file but perhaps that code doesn’t play well with what you want >> to do. >> >> If you go Apple old school on this, it won’t be a problem. It was one of the >> calling cards of WO to do what you are asking… back in the day. >> >> Either that or dig into the Wonder code and see how you can educate the >> properties to do what you want. >> >> Cheers, >> AARON ROSENZWEIG / Chat 'n Bike >> e: aa...@chatnbike.com t: (301) 956-2319 >> >> >> On Feb 24, 2014, at 10:06 AM, David Avendasora <webobje...@avendasora.com> >> wrote: >> >>> Hi all, >>> >>> I’m getting braver (dumber) in my old age. >>> >>> I have decided that for what I want to do I want to keep two independent >>> EOObjectStoreCoordinators each having their own EOModelGroup made up of >>> different Models (okay, fine, They both load erprototypes.eomodeld) but as >>> far as non-prototype EOModel, they don’t share any. >>> >>> There is no data shared between the two OSCs either. I don’t need any >>> cross-OSC relationships, no reading values out of one and writing them into >>> the other so all of those possible mistakes are eliminated. >>> >>> What I *do* need to blend the data from both together in the UI. Seems >>> pretty doable; in practical terms I’ll simply have a WOComponent with two >>> EOEditingContexts, each one a child of one of the two OSC. >>> >>> I have figured out all the stuff I need to do to Create the second OSC and >>> load its EOModels - which I load from a location outside of the Resources >>> directory so I know they are not being automatically loaded at application >>> launch (and I’ve verified that they are not being loaded by. I am >>> programmatically setting the connectionDictionary on the manually loaded >>> EOModel using EODatabaseContext.forceConnectionWithModel(MyModel, >>> connectionDictionary, secondaryEC()). >>> >>> The problem is that it is still trying to connect with the connection >>> information for the models loaded at app launch! I get errors saying that >>> the schema specified in the newly loaded EOModel isn’t in the database. >>> Well, dammit, that’s not the database you should be looking in!!! Ahg! >>> >>> … >>> >>> Um… >>> >>> Errrrrr… Huh. >>> >>> I guess the property like "dbConnectURLGLOBAL=“ and >>> “dbConnectPluginGLOBAL=” mean that the connection information information >>> is used … and here’s the tricky bit … Globally. >>> >>> Funny, that. >>> >>> Still posting to the list so future me will be able to find the answer when >>> I forget what Global means again. I mean really, I’m American. “Global” >>> isn’t a concept I usually bother myself with! >>> >>> Dave >>> >>> ————————————————————————————— >>> WebObjects - so easy that even Dave Avendasora can do it!™ >>> ————————————————————————————— >>> David Avendasora >>> Senior Software Abuser >>> Nekesto, Inc. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>> >>> This email sent to aa...@chatnbike.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/elemgee%40gmail.com >> >> This email sent to elem...@gmail.com > ————————————————————————————— WebObjects - so easy that even Dave Avendasora can do it!™ ————————————————————————————— David Avendasora Senior Software Abuser Nekesto, Inc.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com