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 <[email protected]> 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
> [email protected]
>
>
>
>
>
>
> On Feb 24, 2014, at 10:54 AM, Aaron Rosenzweig <[email protected]> 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: [email protected] t: (301) 956-2319
>>
>>
>> On Feb 24, 2014, at 10:06 AM, David Avendasora <[email protected]>
>> 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 ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
>>>
>>> This email sent to [email protected]
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/elemgee%40gmail.com
>>
>> This email sent to [email protected]
>
—————————————————————————————
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 ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
