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]

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

 _______________________________________________
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]

Reply via email to