Gary,
What we've done is separate our views into multiple environments, leaving most BizObjs with only one updatable view in the DE. For those BizObjs, we have other nonupdatable, lookup views stored in specific DEs suitable for instantiation in a cdeLogical -- these we can either drop on forms for populating combo boxes or create directly in code for use in COM/web services.
I think the cleanest solution will involve determining in your BizObj.Init() which environment you need for each situation, and then populate BizObj.oDELoader.cDataEnvironment property with the name of that environment before calling DODEFAULT() on BizObj.Init(); if you've used the abstract factory pattern before, this might be the time to put it to use for determining the correct DE to load!
Hope that helps,
---J
>I have a situation where my dataenvironments for a bizobj have become very large with the number of views it contains (views for the F/M form, views for Special Utility Methods, views for transactions, etc., all for the same bizobj). I also need to instantiate many of my bizobj's in code instead of dropping them on a form because mutliple application projects use the same classes which had caused each application to have classes from all the other projects added to the other projects when the projects are compiled.
>
>What I would like to know is
>(1)How I can pass a DataEnvironment class name to the bizob/deloader mechanism being instantiated to load a specific dataenvironment (tailored for this task). I don't want to break the timing of having the bizobj / deloader instantiate before form controls do, so the technique has to be close in timming to bizobj / deloader init.
>
>OR
>
>(2) Maybe a combination of instantiating the bizobj without a dataenvironment, passing a parameter through bizobj.init, and then calling this.odeloader.createdataenvironment(tcDataEnvName) would work.
>
>I have thought of using global variables or properties on the application object, but want to stay with "best practices" that other Mere Mortals users may have already developed that is cleaner. As always, Keven, your comments or code snipets are welcome.
>
>Gary Pike.